How Bitcoin Transaction Fees Are Calculated
A Bitcoin fee is based on signed transaction size and the selected fee rate, not the BTC amount being sent. The calculator first estimates transaction weight from the input and output script types, converts weight units to virtual bytes, then multiplies vbytes by satoshis per virtual byte. The final result is rounded up because the fee must be a whole number of satoshis.
Wallets select UTXOs to spend. Each selected UTXO becomes an input, and a payment commonly creates both a recipient output and a change output. Spending more UTXOs usually increases vsize even when the payment amount stays the same. For the broader fee-market context, read How Bitcoin Transaction Fees Work.
- Describe the signed input and output structure
- Estimate base and witness bytes
- Calculate weight and virtual size
- Apply the selected sat/vB rate
- Round the final fee up to a whole satoshi
Weight Units, vBytes and sat/vB
SegWit discounts witness data by counting base bytes at four weight units and witness bytes at one. The transaction weight formula is base size multiplied by three plus total serialized size, which is equivalent to four times the base bytes plus witness bytes. Virtual size is weight divided by four and rounded up.
sat/vB is the fee rate applied to virtual size. A 141 vB transaction at 5 sat/vB has a 705 sat fee. At 0.5 sat/vB, the unrounded product is 70.5 sats and this calculator returns 71 sats. The effective displayed rate then becomes 71 divided by 141 rather than silently changing the entered rate.
| Value | Meaning | Used for |
|---|---|---|
| Weight (WU) | Consensus weight from base and witness serialization | Applying the SegWit discount |
| Virtual size (vB) | Weight divided by four, rounded up | Fee-rate comparison |
| sat/vB | Satoshis paid per virtual byte | Fee selection |
How Input and Output Types Change the Estimate
An input spends an existing UTXO and includes the data needed to authorize that spend. Legacy P2PKH inputs are larger than typical Native SegWit P2WPKH inputs after weight discounting. Taproot key-path spends use Schnorr signatures and a different witness layout. A nested P2SH-P2WPKH spend carries a redeem script in the base transaction as well as witness data.
Outputs lock value to a new script. P2PKH, P2SH, P2WPKH, P2WSH and P2TR scripts have different serialized lengths. The address you pay determines the recipient output type; your wallet and selected change address determine the change output type. Use Satoshi Converter when the task is unit conversion rather than fee estimation.
Worked Bitcoin Fee Examples
A typical Native SegWit profile with one P2WPKH input, one payment output and one change output is estimated at 563 WU or 141 vB. At 10 sat/vB, that produces 1,410 sats. Ten P2WPKH inputs consolidated into one P2WPKH output are estimated at 2,896 WU or 724 vB, showing why input count matters.
The presets are reproducible transaction structures, not promises about a wallet transaction. A wallet can select more UTXOs, omit change, add outputs, use a different script type or produce a slightly different ECDSA signature length. Compare the calculator trace with the final wallet preview.
Live Targets and Manual Fee Rates
Live targets are loaded server-side from mempool.space fee recommendations and cached briefly after validation. Fastest, approximate 30-minute, approximate 60-minute and economy labels describe current recommendation tiers; they do not guarantee a confirmation time because miners choose transactions and mempool conditions can change after the estimate.
Manual mode is useful when a wallet, node or policy gives you a preferred rate. Decimal rates are preserved through the multiplication step, including sub-satoshi-per-vbyte inputs. Only the final total fee is rounded up to a whole satoshi.
What This Calculator Does Not Model
This version models common signed single-signature P2PKH, nested P2SH-P2WPKH, P2WPKH and Taproot key-path inputs. It does not model P2WSH inputs, multisig, Taproot script-path spends, OP_RETURN data, inscriptions or unknown scripts. ECDSA signatures can vary in length, so Legacy and SegWit estimates can differ slightly from the final signed transaction.
The optional USD value reuses the existing reviewed Bitcoin market snapshot. It is a secondary conversion reference and is omitted when that source is unavailable. The sats and BTC fee calculation remains fully usable without market data.
Bitcoin Transaction Fee Calculator FAQ
Does the amount of BTC change the transaction fee?
Not directly. The fee is determined by signed transaction virtual size and sat/vB. The amount can indirectly affect UTXO selection and change, which can alter the structure.
What is a vbyte in Bitcoin?
A virtual byte is transaction weight divided by four and rounded up. Wallets and fee estimators use vbytes to compare fees across Legacy and SegWit transactions.
Why does adding inputs increase the fee?
Each input carries the outpoint, sequence and unlocking data needed to spend one UTXO. More inputs increase transaction weight and therefore increase vsize.
Should I include a change output?
Include change when the selected UTXOs exceed the payment plus fee and the wallet will return the remainder. If the transaction spends the selected value without change, turn it off.
Can Bitcoin fees be below 1 sat/vB?
A manual rate can contain a decimal such as 0.5 sat/vB. Relay and mining policy still determine whether a low-fee transaction propagates and confirms.
Are the live confirmation targets guaranteed?
No. They are current recommendation tiers, not guarantees. Mempool demand and miner selection can change after the estimate is calculated.
Why can my wallet show a different vsize?
The wallet knows the exact selected UTXOs, scripts and final signatures. This calculator uses reviewed typical signed sizes and does not model every script path.
Does the calculator need the BTC price?
No. Weight, vsize, sats and BTC are calculated without price data. BTC/USD is used only for the optional approximate dollar conversion.
Methodology and Sources
The engine uses Bitcoin serialization rules and reviewed typical signed component sizes. The same server-side calculation object powers the initial page, REST updates, target comparison and copy output.
- Base bytes count four WU and witness bytes count one WU; virtual size is weight divided by four and rounded up.
- CompactSize lengths are applied to input and output counts at their documented transition boundaries.
- Fee rate multiplication remains decimal text, and only the final fee is rounded up to a whole satoshi.
- Live fee recommendations are validated and cached server-side; unavailable values never become zero.
- BTC/USD is an optional secondary conversion from the existing Bitcoin market cache and cannot affect the core fee result.
Primary references
- BIP 141: Segregated Witness Transaction weight, virtual size and witness serialization rules.
- BIP 341: Taproot Taproot key-path witness and transaction-spending rules.
- Bitcoin Developer Transaction Reference Raw transaction fields and CompactSize serialization.
- mempool.space REST API Recommended and precise fee-rate endpoint definitions.
Reviewed by the BitcoinToolkit Editorial Team calculation logic last tested