Bitcoin Transaction Fee Calculator

How a Bitcoin transaction fee is calculated

The fee is a product of two numbers: fee = size in vBytes × fee rate in sat/vB. That is the whole formula. Everything else on this page is about where the size comes from, because the fee rate is something you choose and the size is something the transaction imposes on you.

What does not appear anywhere in the formula is the amount being sent. A transaction moving 0.001 BTC and one moving 50 BTC cost the same if they have the same shape. Bitcoin charges for block space, not for value, which is why a payment rail built on it behaves nothing like a percentage-based one.

A fee rate is a bid. Miners fill the next block with the highest sat/vB transactions they have, so the rate decides your position in the queue and the size decides what that position costs you. Raising the rate on a large transaction is expensive in absolute terms; the same rate on a small one is cheap. Both confirm at the same time.

Why vBytes and not bytes

Before SegWit, a block was capped at 1 MB of serialised transaction data and every byte counted the same. SegWit replaced that cap with a 4 million weight-unit limit and gave the two parts of a transaction different weights: base data (everything except the witness) counts 4 weight units per byte, witness data counts 1. The virtual size is the weight divided by four, so vsize = (base bytes × 3 + total bytes) / 4.

The practical effect: signatures moved into the witness, and signatures are the bulk of an input. A legacy P2PKH input carries its signature and public key in the scriptSig, which is base data at full weight, and comes to about 148 vB. A P2WPKH input carries the same material in the witness at a quarter weight and comes to about 68 vB. The bytes on the wire barely changed. What changed is how much of the block they consume.

Because the witness discount divides by four, virtual sizes are frequently fractional. The SegWit marker and flag are two witness bytes, which is half a vByte. The calculator rounds the total up to the next whole vByte, which is what a node does when it reports vsize.

Input and output sizes by address type

These are the single-signature estimates the calculator uses. Inputs differ by a factor of nearly three between the oldest and the newest type; outputs move much less, and Taproot outputs are the largest of the three.

On top of the inputs and outputs sits a fixed overhead: version, the input and output counters, and the locktime. That is 10 vB for a legacy transaction and about 10.5 vB once the SegWit marker and flag are included. The Taproot input figure is 57.5 vB rather than a round number because a Schnorr signature is 64 bytes and lands on a half-vByte after the division by four.

Worked examples

Take the most common shape in the wild: one input, two outputs, where the second output is your own change address.

All-legacy, that is 10 + 148 + 2 × 34 = 226 vB. At 10 sat/vB the fee is 2,260 sat, or 0.00002260 BTC.

All-SegWit, 10.5 + 68 + 2 × 31 = 140.5 vB, rounded up to 141. At the same rate that is 1,410 sat, a reduction of about 38 percent for the identical payment. The saving comes almost entirely from the input.

All-Taproot, 10.5 + 57.5 + 2 × 43 = 154 vB, so 1,540 sat. Taproot loses to SegWit on this shape, because its outputs cost 12 vB more each while its input saves only 10.5 vB. Flip the shape and the ranking flips with it: two inputs and one output give 169 vB for Taproot against 178 vB for SegWit. Taproot pays off when you spend many coins, not when you create many.

Now a consolidation. Twenty P2WPKH inputs into a single output is 10.5 + 20 × 68 + 31 = 1,401.5 vB, rounded to 1,402. At 3 sat/vB that costs 4,206 sat. The same wallet, doing an ordinary payment from one of those inputs, would pay around 423 sat. Ten times the size at a tenth of the rate is the trade a consolidation makes, and it only makes sense while the mempool is quiet.

One pattern runs through all four: the input count is the dominant term. A wallet that has received a hundred small payments holds a hundred UTXOs, and spending them costs a hundred inputs regardless of how little each one is worth. Below some fee rate, a UTXO costs more to spend than it contains.

What the estimate does not cover

The sizes above assume single-signature spends and a uniform address type across all inputs and outputs. Three things move the real number:

Signature length varies. A DER-encoded ECDSA signature is usually 71 or 72 bytes, occasionally 70, so each legacy or P2WPKH input can differ by a byte from the estimate. Schnorr signatures are a fixed 64 bytes, which is why Taproot spends are the only ones whose size is exactly predictable in advance.

Mixed types are normal. Wallets often spend a legacy input and send to a bech32 address with bech32 change. Compute each part with its own row from the table and add the overhead once; the calculator applies one type to everything, which is the right model for a single-wallet transaction and an approximation for anything else.

Multisig and script spends are a different class entirely. A 2-of-3 P2WSH input is several times the size of a single-signature one, and a Taproot script-path spend carries the script and the control block in the witness. Neither is covered here.

Reading and paying fees from code

A fee estimate is only useful next to a current rate, and the rate comes from the mempool, not from a formula. Chaingateway's Bitcoin endpoints take the rate off your hands: POST /api/v2/bitcoin/transactions accepts a speed of fast, medium or slow and selects the fee accordingly, plus a subtractfee flag that takes the fee out of the amount being sent rather than adding it on top. That flag matters more than it looks: it is the difference between a recipient receiving exactly what your invoice said and receiving slightly less.

The full endpoint list, including blocks, wallets and transaction webhooks, is on the Bitcoin API page. Other calculators and reference tools are collected under Tools.

Questions

How is a Bitcoin transaction fee calculated?

Size in vBytes multiplied by the fee rate in satoshi per vByte. A 141 vB transaction at 10 sat/vB pays 1,410 sat. The amount you are sending never enters the calculation.

What is a vByte?

A virtual byte, the unit blocks are measured in since SegWit. A transaction's weight counts base data at 4 units per byte and witness data at 1, and the vsize is that weight divided by four. Witness bytes therefore cost a quarter of what base bytes cost.

How large is a typical Bitcoin transaction?

For one input and two outputs: about 226 vB all-legacy, 141 vB all-SegWit, 154 vB all-Taproot. Each extra input adds 148, 68 or 57.5 vB depending on the type, which is why input count drives the fee more than anything else.

Does the amount I send change the fee?

No. Bitcoin charges for block space. Sending 0.001 BTC and sending 50 BTC cost the same if both transactions have the same number of inputs and outputs and the same address types.

Why do more inputs make a transaction more expensive?

Every coin you spend is a separate input carrying its own signature, and a signature is most of an input's size. Ten small UTXOs cost ten inputs to spend. This is the reason wallets consolidate during quiet periods, when the sat/vB rate is low enough to make a large one-off transaction cheap.

What does sat/vB mean?

Satoshi per virtual byte, the price you bid for block space. One satoshi is 0.00000001 BTC, so 100,000,000 sat make one BTC. Miners sort the mempool by this rate, which is why the rate rather than the total fee decides how quickly a transaction confirms.

Is Taproot cheaper than SegWit?

Only when the transaction is input-heavy. A P2TR input is about 57.5 vB against 68 vB for P2WPKH, but a P2TR output is 43 vB against 31 vB. One input and two outputs comes to 154 vB with Taproot and 141 vB with SegWit; two inputs and one output reverses that, 169 vB against 178 vB.

Why does my wallet show a slightly different fee?

Three usual causes. ECDSA signatures vary between 70 and 72 bytes, so each legacy or P2WPKH input can be a byte off the estimate. Wallets frequently mix address types between the inputs, the payment output and the change output. And a wallet picks its own fee rate from its own mempool view, while this calculator uses the rate you type in.