How Bitcoin Transaction Fees Work

Direct Answer

Bitcoin fees depend on transaction virtual size, fee rate and changing demand for block space—not simply the amount sent.

Two Bitcoin payments can send the same amount and pay very different network fees. The difference is not the value being transferred. It is the transaction the wallet has to build: which unspent outputs become inputs, how many new outputs are created, what script types are involved, how much serialized data the signed transaction contains, and what fee rate the wallet applies to that virtual size.

This is why a wallet can show one fee before coin selection and another after the final inputs are chosen. It is also why sending 0.01 BTC can cost more than sending 1 BTC. Bitcoin does not charge a percentage of the payment. It prices block space.

The calculation follows one continuous path:

Inputs and outputs
→ serialized transaction data
→ transaction Weight
→ virtual size in vB
→ fee rate in sat/vB
→ total fee in sats

Understanding that path lets you read a wallet fee preview without confusing the payment amount, the fee rate, and the final fee.

The Fee Is Not a Percentage

A Bitcoin transaction fee is the difference between the total value of its inputs and the total value assigned to its outputs:

Transaction fee
=
Total input value
−
Total output value

Suppose a wallet spends one input worth 120,000 sats. It creates a 100,000-sat payment output and an 18,500-sat change output. The remaining 1,500 sats are the transaction fee:

120,000 sats
− 100,000 sats
− 18,500 sats
= 1,500 sats fee

The network does not separately withdraw that fee from an account. The fee is the input value the transaction does not assign to a new output.

A wallet can present several related figures on the same screen. They describe different parts of the transaction and should not be compared without their units.

Displayed value	What it means	Example
Recipient amount	Bitcoin assigned to the intended recipient output	100,000 sats
Total fee	Input value not assigned to any output	1,500 sats
Fee rate	Price applied per virtual byte	10 sat/vB
Virtual size	Weighted transaction size used for fee comparison	150 vB
Total wallet debit	Recipient amount plus the fee when the sender pays it separately	101,500 sats

The payment amount and total fee are measured in sats or BTC. The fee rate is measured in sat/vB. Virtual size is measured in vB. If those labels are unfamiliar, first read what a satoshi means in wallets and fee displays.

Inputs and Outputs Set the Size

Inputs spend existing UTXOs

Bitcoin wallets do not spend from one account balance. They spend existing unspent transaction outputs, commonly called UTXOs. Every selected UTXO becomes an input in the new transaction.

An input identifies a previous output and supplies the data required to satisfy that output’s spending conditions. Depending on the script type, some authorization data appears in the base transaction serialization and some appears in the witness.

A displayed balance can hide the structure that matters for fees. A wallet showing 500,000 sats might control:

• one UTXO worth 500,000 sats;
• five UTXOs worth 100,000 sats each;
• or fifty UTXOs worth 10,000 sats each.

All three wallets show the same total balance. Spending from them does not create the same transaction. More selected UTXOs generally mean more inputs, and every additional input brings another outpoint, sequence field, script or witness data, and length prefix into the serialized transaction.

A 50,000-sat payment funded by one suitable UTXO can therefore be smaller than the same payment funded by eight small UTXOs. Coin selection also changes privacy and the wallet’s future UTXO set. To compare the cost of consolidating UTXOs now with spending them separately later, use the Bitcoin UTXO Consolidation Calculator.

Recipient and change outputs

A transaction output contains an integer value in satoshis and a locking script. The recipient payment is one output. Change returned to the sender is usually another.

If a wallet selects a 120,000-sat UTXO to make a 100,000-sat payment, it normally cannot spend only part of that UTXO. The new transaction consumes the complete output. After the fee is accounted for, the unused value returns to a wallet-controlled change output.

A typical payment can therefore contain one or more inputs, a recipient output, a change output, and fixed fields such as version and locktime. It also contains input and output counts, and each input has its own sequence value.

Adding another recipient adds an output. Adding change adds one as well. Each output increases transaction size, although an ordinary single-signature input usually adds more virtual size than an ordinary output.

A wallet can avoid change when the selected input value closely matches the payment plus fee. It can also add a very small remainder to the fee instead of creating an uneconomical change output. That decision depends on the wallet’s coin selection and policy rules, which is why “one payment” is not enough information to reproduce a fee.

Bytes, Weight and vSize

Bitcoin transactions are serialized into bytes. The raw structure includes a version, input count, inputs, output count, outputs, and locktime. SegWit transactions also include a marker, flag, and witness fields.

Before SegWit, fee comparisons often referred directly to transaction bytes. BIP 141 introduced transaction Weight so witness data could contribute differently from non-witness data.

BIP 141 defines Weight as:

Transaction Weight
=
Base transaction size × 3
+
Total transaction size

The same relationship can be written as:

Transaction Weight
=
Non-witness bytes × 4
+
Witness bytes

A non-witness byte contributes four weight units. A witness byte contributes one. The lower weighting does not make witness data free; it still consumes block Weight and still increases the fee-relevant size.

Wallets and fee markets commonly express the result in virtual bytes, abbreviated vB:

vSize
=
ceil(Transaction Weight ÷ 4)

The division rounds upward to a whole virtual byte. Base size, total serialized size, Weight, and vSize are related measurements, but they are not interchangeable. Base size excludes witness-related data. Total size includes the complete serialization. Weight applies the four-to-one rule. vSize turns that Weight into the integer size used for common fee-rate calculations.

sat/vB Prices the Transaction

The common Bitcoin fee-rate unit is satoshis per virtual byte, written sat/vB. Once the transaction structure has produced a vSize, the simplified fee calculation is:

Estimated fee in sats
=
Transaction vSize
×
Fee rate in sat/vB

The units cancel cleanly: virtual bytes multiplied by satoshis per virtual byte leave a total number of satoshis.

The rate and the total fee answer different questions:

• Fee rate: how much the transaction pays for each unit of virtual size.
• Total fee: how many satoshis the complete transaction pays.

A large transaction can pay a high total fee at a moderate rate. A compact transaction can pay a lower total even at a higher rate. Comparing only the total fee hides the difference between transaction size and fee-market urgency.

Once the final signed transaction is known, its effective fee rate can be calculated from the actual fee and actual vSize:

Effective fee rate
=
Actual fee in sats
÷
Actual vSize in vB

The effective rate can contain a decimal even though the transaction fee itself is a whole number of satoshis.

A wallet or calculator can also accept a decimal fee-rate target. The transaction fee itself still resolves to an integer number of sats because input and output values are integers. When the multiplication produces a fractional satoshi, the implementation must choose a whole-satoshi fee. Rounding upward avoids falling below the requested target rate, which can make the final effective rate slightly higher than the value entered.

A Reproducible Fee Calculation

The following example models one common signed transaction structure:

• 2 Native SegWit P2WPKH inputs;
• 1 P2WPKH recipient output;
• 1 P2WPKH change output;
• CompactSize counts that each fit in one byte;
• 72-byte serialized ECDSA signatures in the witness;
• and a selected fee rate of 12 sat/vB.

This is an illustrative technical model, not a user transaction record or a claim about a specific wallet. Final ECDSA signature lengths can vary, so a wallet can reserve a slightly different maximum input Weight before signing.

From serialization to the final fee

The two P2WPKH inputs contribute 41 base bytes each. The two P2WPKH outputs contribute 31 bytes each. Fixed fields and one-byte input and output counts contribute another 10 base bytes. Each modeled input carries 108 witness bytes: one stack-item count byte, one signature-length byte, a 72-byte serialized signature, one public-key-length byte, and a 33-byte compressed public key.

Component	Base bytes	Witness bytes	Weight contribution
Version, counts, and locktime	10	0	40 WU
Two P2WPKH inputs	82	216	544 WU
Two P2WPKH outputs	62	0	248 WU
SegWit marker and flag	0	2	2 WU
Total	154	218	834 WU

Weight
= (154 base bytes × 4) + 218 witness bytes
= 834 WU

vSize
= ceil(834 ÷ 4)
= 209 vB

Fee
= 209 vB × 12 sat/vB
= 2,508 sats

Every assumption is visible. Change the input count, output count, script type, witness size, or fee rate, and the result changes. To model mixed input and output types, open the Bitcoin Transaction Fee Calculator, enter the structure shown by the wallet, and compare the estimate with the final transaction preview.

Same Payment, Different Fee

Consider two wallets that each send the same 100,000-sat payment, create one P2WPKH change output, and use a 12 sat/vB fee rate. The only difference is the number of P2WPKH inputs.

Using the same 72-byte-signature model as the worked example:

Modeled transaction	Inputs	Outputs	Weight	vSize	Fee at 12 sat/vB
Wallet A	1 P2WPKH	2 P2WPKH	562 WU	141 vB	1,692 sats
Wallet B	8 P2WPKH	2 P2WPKH	2,466 WU	617 vB	7,404 sats

The recipient receives the same amount. The fee rate is the same. Wallet B pays more because it spends more inputs and creates a larger transaction.

The amount can be unchanged. The transaction structure is not.

A fee estimate that does not know the wallet’s actual UTXOs is therefore a scenario, not the final transaction. The wallet must select real inputs before it can determine the likely size and fee.

Input Type Changes the Cost

Input count is not the only structural variable. The spending conditions of the selected outputs determine what each input must serialize.

Common single-signature profiles include Legacy P2PKH, nested SegWit P2SH-P2WPKH, Native SegWit P2WPKH, and Taproot key-path P2TR. They do not add the same Weight.

Common input profile	Where authorization data appears	Illustrative marginal size	Important boundary
P2PKH	Base transaction scriptSig	About 148 vB	ECDSA signature length can vary
P2SH-P2WPKH	Redeem program in scriptSig plus witness	About 91 vB	Nested SegWit includes wrapper data
P2WPKH	Witness	About 68 vB	ECDSA signature length can vary
P2TR key path	Single Schnorr signature in witness	About 58 vB	A non-default sighash byte adds one byte

These figures describe common single-signature spending paths, not every possible transaction. Multisig, P2WSH, Taproot script paths, inscriptions, complex scripts, and nonstandard constructions can carry very different witness data.

Output type matters too, although a receiving address does not reveal the exact future input cost in every case. For a focused comparison of address encodings, compatibility, and common script families, read Bitcoin address types and their wallet implications.

Why Wallet Estimates Change

A wallet fee estimate can change between the payment form and the signing screen even when the recipient amount stays the same. Several transaction-building decisions can still be unresolved when the first estimate appears.

Coin selection and change are provisional

The wallet can initially model one input count, then select a different set after considering confirmation status, coin-control settings, privacy rules, change avoidance, or the need to cover the fee. Once the inputs are known, it can add, remove, or change the type of a change output.

Bitcoin Core’s fundrawtransaction documentation reflects these choices: a wallet can add inputs, create at most one change output, select a change type, use a fee rate in sat/vB, or subtract the fee from specified outputs. Adding an input increases Weight. Adding change increases output size. Subtracting the fee changes the recipient amount. Avoiding a tiny change output can move the remainder into the fee.

Signatures and fee rates are estimated

ECDSA signatures are not guaranteed to have identical serialized lengths. Bitcoin Core’s transaction-funding documentation advises using the maximum serialized DER signature size when an external input Weight estimate is supplied. A wallet can therefore reserve a safe maximum before the actual signatures exist.

The fee rate can also refresh before signing. If the wallet receives a newer estimate or the user changes the confirmation target, the selected sat/vB rate changes even when the transaction structure does not.

These are not random discrepancies. A changed fee should map to a changed input set, output structure, signature-size assumption, fee-rate estimate, or some combination of them.

Network Demand Sets the Rate

Transaction structure determines vSize. Network conditions influence the rate a wallet chooses for a confirmation target.

Bitcoin block space is limited. Unconfirmed transactions compete for inclusion, and fee rate is one of the main signals used to compare how much each transaction pays relative to its virtual size. A wallet can select a higher rate for a more aggressive target or a lower rate when the user accepts more delay.

Bitcoin Core’s estimatesmartfee RPC returns an approximate fee rate for a transaction to begin confirmation within a requested number of blocks when sufficient data is available. It uses virtual transaction size and provides two estimation modes:

• Economical responds more quickly to short-term fee-rate drops and can return a lower estimate.
• Conservative uses a longer history, responds more slowly to short-term drops, and can return a higher estimate.

Neither mode reserves block space. The estimate is based on observed behavior, not a promise that a miner will include the transaction in a particular block.

Wallets, explorers, and services can use different time windows, mempool views, safety margins, and target labels. Two interfaces can therefore recommend different rates at the same moment without applying different Bitcoin consensus rules.

There is no single global mempool queue that every node sees in exactly the same order. Nodes receive transactions at different times and apply their own policy settings. A wallet estimate describes the data available to its fee source; a miner ultimately selects from the transactions and policies available to that mining operation.

The Final Signed Transaction

Before signing, a wallet estimates the authorization data required for each input. After signing, the transaction contains the actual signatures and witness stacks. The final serialization reveals the real Weight, vSize, total fee, and effective fee rate.

The signing screen should therefore be treated as more authoritative than an early amount-entry estimate. It can reveal that the wallet selected more inputs than expected, added change, used a different output type, produced a different signature size, or refreshed the fee rate before authorization.

The payment details can be correct while the transaction structure still deserves another review. Check both before broadcasting.

Fee changes after broadcast

Broadcasting sends the transaction to peers. It does not guarantee that every node will accept and retain it or that it will appear in the next block. New transactions can enter the fee market after yours, making the original rate less competitive.

Some wallets can create a higher-fee replacement when an unconfirmed transaction is eligible for fee bumping. Bitcoin Core’s bumpfee workflow can reduce change or add inputs when necessary, which means the replacement transaction’s size and total fee can both differ from the original.

Read the Final Wallet Preview

Before signing, check the figures that establish the fee instead of relying on a single “network fee” line.

1. Recipient amount: Confirm the amount assigned to the intended recipient and whether the fee is deducted from that output.
2. Selected inputs: A larger-than-expected input count explains many fee increases.
3. Outputs and change: Confirm the recipient outputs, change output, and change destination.
4. Virtual size: Review the vB figure when the wallet exposes it.
5. Fee rate: Distinguish a rate in sat/vB from the absolute fee in sats.
6. Total fee: Confirm the total satoshis the complete transaction pays.
7. Confirmation target: Treat it as an estimate and note whether the wallet can later increase the fee.

The most useful cross-check is arithmetic:

Does the displayed vSize × displayed sat/vB
approximately match the displayed fee in sats?

A small difference can come from a decimal fee rate, whole-satoshi rounding, or rounded display values. A large unexplained difference deserves another review before signing.

For broader context on UTXOs, confirmations, miners, and validation, continue to the Bitcoin network and transaction reference.

What the estimate cannot guarantee

A complete fee estimate can describe the transaction and the selected rate. It cannot guarantee:

• confirmation in the next block or at an exact time;
• acceptance and continued retention by every node;
• unchanged network demand after the transaction is signed;
• or that the wallet chose the most private and economical inputs or will never need a fee bump.

The reproducible question is narrower: given this transaction structure and this fee rate, how many satoshis does the transaction pay? Confirmation timing remains probabilistic.

Bitcoin Transaction Fee FAQ

Are Bitcoin transaction fees based on the amount sent?

No. Bitcoin transaction fees are based mainly on transaction virtual size and the selected fee rate. The amount sent can affect which UTXOs a wallet needs, but a larger payment does not automatically create a larger fee.

What does sat/vB mean?

Sat/vB means satoshis per virtual byte. It is a fee rate applied to a transaction’s virtual size. Multiplying vSize by the fee rate gives a modeled total fee in satoshis.

Why did my Bitcoin wallet fee change before I signed?

The wallet can select different inputs, add or remove change, update the change type, reserve a different signature size, or refresh the fee rate. Any of those changes can alter the final fee.

Why can two wallets charge different fees for the same payment?

The wallets can control different UTXOs, choose different inputs, create different change outputs, use different fee-rate estimates, or apply different safety margins. The recipient amount can be the same while the transaction structures differ.

Does a higher Bitcoin fee guarantee faster confirmation?

No. A higher fee rate can improve a transaction’s relative priority, but it cannot guarantee a particular block. Future demand, miner selection, mempool policy, and block discovery remain outside the wallet’s control.

Can a Bitcoin fee be increased after broadcast?

Some wallets can create a higher-fee replacement when the original transaction is eligible for fee bumping. The replacement can reduce change or add inputs, so its transaction size and total fee can both change.

Technical Sources

The formulas and transaction-building boundaries in this guide are based on primary Bitcoin specifications and Bitcoin Core documentation.

• BIP 141: Segregated Witness — defines transaction Weight, base size, total size, and virtual transaction size.
• Bitcoin Developer Transaction Reference — documents serialized inputs and outputs and explains that output values are recorded in satoshis.
• Bitcoin Core 31.0 estimatesmartfee RPC — documents confirmation-target fee-rate estimation, virtual-size use, and economical and conservative modes.
• Bitcoin Core 31.0 fundrawtransaction RPC — documents automatic input selection, change creation, fee-rate settings, fee subtraction, and input-Weight assumptions.
• Bitcoin Core 31.0 bumpfee RPC — documents wallet fee replacement and how a higher-fee transaction can reduce change or add inputs.
• BIP 341: Taproot — defines Taproot key-path signatures and witness behavior used in the common P2TR input-size model.

Sources

1. BIP 141: Segregated Witness weight and virtual size
2. Bitcoin Core send RPC: fee_rate in sat/vB
3. Bitcoin Core estimatesmartfee RPC

Found an error? Report a content issue or read our Corrections Policy.