Bitcoin Transaction Fee Calculator
Solve the Bitcoin fee relation Fee = Size × Rate for any of its three unknowns — the total fee in sats and BTC, the maximum transaction size your budget allows, or the fee rate you can afford in sat/vB — with step-by-step maths, a live size meter, and a full set of mempool metrics.
SegWit cut the size of every input
Before SegWit activated in 2017, every byte of a transaction counted equally toward the block limit. SegWit introduced the concept of weight, where witness data — the signatures that make up most of an input — counts at one quarter the rate of the rest of the transaction. Virtual size is weight divided by four. The result is that a native SegWit input is roughly 41 vB instead of 148 bytes, cutting fees by about 40% for the same transaction. Taproot in 2021 pushed this further with smaller keys and cheaper multisig.
The fee rate is a mempool auction
Bitcoin blocks have a fixed weight limit of 4 million weight units (about 1 million vB). When more transactions want in than fit, miners fill the block with the highest-paying ones first. The fee rate you choose determines where you sit in that queue: at 100 sat/vB you go in the next block; at 1 sat/vB you wait until the queue clears. The "going rate" quoted by mempool.space is simply the fee rate above which blocks have recently been filling, and below which they have not.
Fees are volatile within a day
On a quiet week the fee rate can sit at 1–3 sat/vB for hours. During an ordinal mint or an exchange withdrawal wave it can spike above 100 sat/vB within minutes and fall back just as fast. This is because the mempool has no smoothing mechanism — it is a pure auction, and demand arrives in bursts. If a transaction is not urgent, waiting a few hours or a weekend can cut the fee by 80% or more. Wallets now offer a "no rush" mode that simply waits for the rate to fall to your chosen level.
Lightning moves small payments off-chain
The fee formula applies to on-chain transactions, where every payment must be written into a block. For small, frequent payments — buying coffee, tipping, streaming sats — the Lightning Network routes transactions through off-chain channels and only settles the net result to the chain occasionally. A Lightning payment costs a fraction of a sat regardless of on-chain conditions, because it is not competing for block space. On-chain fees are for settlement and large transfers; Lightning is for everything smaller.
How to Use This Calculator
The Bitcoin fee relation links three quantities: the total fee, the transaction size, and the fee rate. Choose which one the tool should solve, then fill in the rest.
1. Choose what to solve for
Pick Fee, Size, or Rate from the toggle. The calculator rearranges Fee = Size × Rate automatically for whichever you choose.
2. Set your transaction size
Use the presets: 141 vB for a 1-in 2-out native SegWit send, 111 vB for Taproot, 226 vB for legacy P2PKH. Your wallet will show the exact size before you broadcast.
3. Read the current fee rate
Check mempool.space or your wallet's estimate. Normal mainnet conditions run 10–30 sat/vB; quiet periods 1–5; congestion 50+ sat/vB. The presets span this range.
4. Enter your BTC price for dollar figures
The fee is always computed in satoshis. Enter the BTC/USD rate to see the dollar cost — the number that matters when comparing against Lightning or deciding whether to wait.
5. Read the result and verdict
The result card shows the fee in sats and BTC with a colour-coded verdict from negligible to prohibitive. The fee breakdown repeats size, rate, fee in sats and fee in USD.
6. Switch to Advanced to compare and budget
Advanced mode adds a second chart, sensitivity on ±1% moves, a table pricing every common transaction type at the current rate, and a scenario table showing what the same transaction costs at every fee rate from 1 to 300 sat/vB.
What This Tool Offers
Built around the classic Bitcoin fee relation Fee = Size × Rate, the fundamental link between transaction weight and confirmation cost.
Three-way solving
Solve for the fee, the maximum virtual size your budget allows, or the fee rate you can afford. The calculator rearranges the formula for whichever you choose.
Transaction-type presets
One click for P2WPKH, Taproot, P2SH-P2WPKH, legacy P2PKH, and 2-of-3 multisig — with the virtual size each one actually consumes.
Fee meter schematic
A three-panel meter showing size, rate and fee as proportional bars, linked by × and = signs, with a comparison against a standard SegWit send.
Operation cost table
The advanced panel prices every common transaction type at the current fee rate and BTC price, so you can see at a glance what a send, a consolidation or a multisig would cost right now.
Fee rate scenarios
What the same transaction costs at 1, 3, 5, 10, 20, 50, 100, 200 and 300 sat/vB — the table that tells you whether to broadcast now or wait for the mempool to clear.
Reference tables
A unit converter across sats, BTC and USD, a fee lookup grid across size and rate, and a full table of common Bitcoin transaction types with their virtual sizes.
Reference Tables & Conversions
A fee unit converter, a fee lookup grid, and the virtual size of every common Bitcoin transaction.
Fee unit converter
Fee Lookup — Fee = Size × Rate
Rows are transaction size in vB; columns are fee rate in sat/vB. Values are in satoshis.
| Size ↓ / Rate → | 1 | 3 | 5 | 10 | 20 | 50 | 100 | 300 |
|---|
Virtual Size of Common Bitcoin Transactions
Approximate virtual bytes for the most common transaction shapes. Smaller and newer address types are cheaper at any given fee rate.
| Transaction type | Shape | Virtual size | Notes |
|---|---|---|---|
| P2WPKH send | 1-in, 1-out | ~110 vB | Native SegWit, single recipient |
| P2WPKH send | 1-in, 2-out | ~141 vB | Native SegWit, recipient plus change |
| P2TR send | 1-in, 2-out | ~111 vB | Taproot — cheapest common send |
| P2SH-P2WPKH | 1-in, 2-out | ~167 vB | Wrapped SegWit — older wallets |
| P2WPKH consolidation | 2-in, 2-out | ~208 vB | Combining two UTXOs |
| P2WPKH consolidation | 3-in, 2-out | ~250 vB | Combining three UTXOs |
| P2PKH legacy | 1-in, 2-out | ~226 vB | Legacy addresses — most expensive |
| 2-of-3 multisig | 2-in, 2-out | ~350 vB | P2SH multisig, no SegWit |
| P2WSH multisig | 2-of-3, 2-out | ~250 vB | SegWit multisig — much cheaper |
| Taproot script spend | 1-in, 2-out | ~130 vB | Complex script, still compact |
| Batch send (10 outputs) | 1-in, 10-out | ~300 vB | Amortises input cost across recipients |
| Batch send (50 outputs) | 1-in, 50-out | ~1,100 vB | Used by exchanges for withdrawals |
Fee Rate Reference
What different fee rate levels mean in practice on the Bitcoin mainnet mempool.
| Fee rate | Conditions | Typical confirmation | 141 vB send costs | 226 vB legacy costs |
|---|---|---|---|---|
| 1 sat/vB | Minimum relay — very quiet | Hours to days | 141 sats | 226 sats |
| 2–3 sat/vB | Quiet weekends | A few blocks to hours | 282–423 sats | 452–678 sats |
| 5–8 sat/vB | Low normal | Next few blocks | 705–1,128 sats | 1,130–1,808 sats |
| 10–20 sat/vB | Normal | Next block | 1,410–2,820 sats | 2,260–4,520 sats |
| 30–60 sat/vB | Busy | Next block, competitive | 4,230–8,460 sats | 6,780–13,560 sats |
| 80–150 sat/vB | Congested | Requires overbidding | 11,280–21,150 sats | 18,080–33,900 sats |
| 200–500 sat/vB | Extreme — ordinal mints, exchange waves | Auctions, front-running | 28,200–70,500 sats | 45,200–113,000 sats |
| 1,000+ sat/vB | Historic spikes | May still fail | 141,000+ sats | 226,000+ sats |
Variable Reference
| Symbol | Meaning | Typical range | Units |
|---|---|---|---|
| Fee | Total transaction cost | 100 – 1,000,000+ | sats |
| Size | Virtual size of the transaction | 110 – 3,000 | vB |
| Rate | Price per virtual byte | 1 – 500+ | sat/vB |
| Weight | Transaction weight = 4 × vB | 440 – 12,000 | weight units |
| BTC | Fee in bitcoin | 0.000001 – 0.01 | BTC |
| USD | Fee in US dollars | 0.01 – 1,000+ | USD |
What Does Fee = Size × Rate Measure?
The Bitcoin fee relation answers the simplest question in on-chain usage: what will this transaction cost me? It does so by multiplying the amount of block space the transaction occupies, measured in virtual bytes, by the price the mempool is currently charging per virtual byte. Size is a property of the transaction; rate is a property of the network at the moment you broadcast. The fee is their product.
Virtual bytes exist because Bitcoin blocks have a fixed capacity — 4 million weight units, about 1 million vB — and every transaction must compete for a slice of that capacity. The number of transactions the network can settle per second is bounded by this limit, and when demand exceeds supply, the price of inclusion rises. This is why Bitcoin fees are described as an auction: users bid, miners fill the block with the highest bids, and the "market rate" is simply the level at which recent blocks have been filling.
The Bitcoin Fee Formula
The defining relationship is:
With size in vB, rate in sat/vB and fee in sats:
Fee (BTC) = Fee (sats) / 100,000,000
Fee (USD) = Fee (BTC) × BTC price
Rearranged to solve for the other two unknowns:
Rate = Fee / Size
Virtual size itself derives from the transaction weight:
vB = Weight / 4 = Base size + Witness size / 4
This is why SegWit transactions are cheaper: the witness — mostly signatures — is discounted to a quarter of its byte count, so a SegWit input weighs far less than a legacy one even though it does the same job.
Bitcoin Fee Variables
| Symbol | Meaning | Notes |
|---|---|---|
| Fee | Total transaction cost | Size × rate; what you actually pay |
| Size | Virtual size | Fixed by the transaction's shape; your wallet shows it before broadcast |
| Rate | Fee rate | sat/vB; set by the mempool auction |
| Weight | Transaction weight | 4 × vB; the raw capacity measure |
| Block weight | Capacity per block | 4,000,000 weight units, ≈1,000,000 vB |
| RBF | Replace-by-fee | Flag allowing a stuck tx to be re-broadcast at a higher rate |
How Each Variable Affects the Fee
The fee is linear in both size and rate. Doubling the number of inputs doubles the size and therefore doubles the fee at the same rate; doubling the rate doubles the fee at the same size. But the two variables behave very differently. Size is a property of your transaction and is largely fixed once you decide what you want to spend — though you can reduce it by consolidating UTXOs during quiet periods, using SegWit or Taproot addresses, and batching payments. Rate is set by the market and fluctuates continuously.
The most common surprise for new users is how quickly the fee rate can move. A transaction broadcast at 20 sat/vB during a quiet weekday morning might wait behind a sudden wave of ordinals and take hours instead of minutes. The inverse also happens: a fee rate that looks high on a Tuesday can look trivial by Saturday night. If a transaction is not urgent, most wallets now offer a "no rush" mode that simply sets a low rate and lets the transaction sit in the mempool until the queue clears to your level — sometimes saving 90% or more versus broadcasting immediately.
Size reduction is the other lever, and it is under your control in a way the fee rate is not. Every additional input costs roughly 68 vB in native SegWit, and every additional output costs about 31 vB. A transaction with three inputs is nearly twice as large as one with a single input, and therefore nearly twice as expensive at the same rate. Consolidating UTXOs during quiet periods — sending many small outputs to yourself in a single transaction — costs a little now but saves a lot later when you actually want to spend. This is why experienced users are happy to pay 5 sat/vB for a consolidation on a Sunday night.
Bitcoin Fee Calculation Examples
Fee = 141 × 20 = 2,820 sats
Fee = 2,820 / 100,000,000 = 0.0000282 BTC
Fee = 0.0000282 × 65,000 = $1.83
Fee = 226 × 20 = 4,520 sats = 0.0000452 BTC = $2.94 at $65,000/BTC
Fee = 141 × 100 = 14,100 sats = 0.000141 BTC = $9.17 at $65,000/BTC
Rate = 5,000 / 141 = 35.46 sat/vB
Size = 2,000 / 8 = 250 vB
At 20 sat/vB: 141 × 20 = 2,820 sats
At 3 sat/vB: 141 × 3 = 423 sats
Waiting for a quiet window saves 2,397 sats — 85% of the fee.
Frequently Asked Questions
Because the preset assumes a simple shape — one input, two outputs, all native SegWit. Real transactions often differ. Each additional input adds about 68 vB in native SegWit or 148 bytes in legacy. Each additional output adds about 31 vB. If you are spending a UTXO that came from a legacy address, its input is heavier than a SegWit one. And multisig inputs are much larger because they carry multiple signatures. Your wallet will always show the actual size before you sign, and that figure is the one to use for fee estimation.
Before SegWit, every byte of a transaction counted equally and the fee rate was quoted in sat/byte. After SegWit activated, the notion of weight was introduced: witness data — signatures and other unlocking scripts — counts at one quarter the rate of the rest. Weight divided by four gives virtual size. Blocks are limited by weight, not by bytes, so the meaningful fee rate is sat per virtual byte. For a legacy transaction with no witness data, weight equals four times the byte count, so sat/vB and sat/byte are identical. For SegWit transactions, vB is smaller than the raw byte count, which is exactly the discount SegWit provides.
Look at mempool.space, which shows three levels: the low-priority rate that may confirm in hours or a day, the medium-priority rate targeting the next few blocks, and the high-priority rate targeting the very next block. For an ordinary payment, the medium rate is usually right. For something urgent — an exchange deposit with a deadline, a collateral top-up — use high. For anything that can wait, use low and let the transaction sit; if you enabled RBF in your wallet, you can always bump it later. Never set a rate below 1 sat/vB on mainnet, because most nodes will not relay it.
Bitcoin's fee market has no smoothing mechanism — it is a pure auction, and demand arrives in bursts. Common causes of spikes include an ordinal or BRC-20 mint that fills blocks with inscription transactions, a large exchange processing a withdrawal backlog, a popular airdrop or token sale on a Bitcoin layer, and occasional spam attacks designed to stress the network. Spikes can push the rate from 3 to 100 sat/vB within a few minutes and back down again just as fast. If your transaction is already broadcast and not urgent, leave it — it will confirm when the queue clears. If you need it confirmed during the spike, use replace-by-fee to bump the rate.
Replace-by-fee (RBF) is a flag a transaction can carry that says "I might replace this with a higher-fee version later." Before RBF, a broadcast transaction was essentially final — if the fee rate turned out to be too low, you were stuck waiting. With RBF enabled, you can rebroadcast the same transaction at a higher fee rate, and miners will take the replacement. Most modern wallets enable RBF by default. The trade-off is that a transaction flagged RBF can also be replaced by someone else — an issue for zero-confirmation payments, which is why some merchants wait for one or more confirmations on RBF-flagged transactions.
Three levers, in order of impact. First, use the cheapest address type your wallet supports: native SegWit (bc1q…) or Taproot (bc1p…) instead of legacy (1…) or wrapped SegWit (3…), which cuts the size of every input. Second, consolidate UTXOs during quiet periods — a single consolidation transaction at 3 sat/vB can save many times its own cost when you later need to spend. Third, time your transactions: fee rates are lowest on weekends and at night in US and European time, often 80–90% below peak. For small or frequent payments, move them to Lightning, where fees are a fraction of a sat and independent of mainnet conditions.
Your transaction stays in the mempool, unconfirmed, until the fee rate falls to your level or you replace it. Bitcoin nodes do not forget pending transactions quickly — a low-fee transaction can sit for days or weeks and still be included if the mempool clears. If you need it confirmed sooner, use RBF to bump the rate. The one thing you cannot do is broadcast the same UTXO in a different transaction while the original is still pending: the network will reject the second one as a double-spend attempt. This is why wallets serialise transactions from the same address — a pending transaction blocks all later ones until it confirms or is replaced.
Variables
| Symbol | Quantity | Unit |
|---|---|---|
| Total Fee | Total transaction fee | satoshis |
| Transaction Size | Transaction size | vBytes |
| Fee Rate | Fee rate per virtual byte | sat/vByte |
What it means
Bitcoin transaction fees are based on the size of the transaction in virtual bytes (vBytes) and the fee rate in satoshis per vByte. The fee rate is chosen by the user to influence confirmation speed. This is used to estimate transaction costs and to set appropriate fees during times of network congestion. Understanding this helps users avoid overpaying and to get timely confirmations. It is a key aspect of using the Bitcoin network and is also applicable to other UTXO‑based chains.
Worked example
Bitcoin Transaction Fee Rate – Two Detailed Examples
Real‑World| Parameter | Value |
|---|---|
| Tx Size (vBytes) | 140 |
| Fee Rate (sat/vByte) | 20 |
| Parameter | Value |
|---|---|
| Tx Size | 225 |
| Fee Rate | 50 |
Common mistakes
- Transaction size (vBytes): The virtual size of the transaction in bytes (segwit discount applied).
- Fee rate (sat/vByte): The fee per virtual byte in satoshis.
- Total fee: In satoshis – convert to BTC or USD as needed.
- Priority: Higher fee rate increases confirmation speed.
Applications
Bitcoin transaction fee rate calculates the total fee by multiplying the transaction size (in vBytes) by the fee rate (in sat/vByte). This is how Bitcoin fees are determined, based on the data size rather than the transaction value. Users and wallets use this to estimate fees and to set appropriate rates for timely confirmation. By understanding the fee rate, users can prioritise transactions during congestion and can save on fees by using lower rates during quieter periods. This formula is essential for any Bitcoin user.
- Estimating Bitcoin transaction fees for sending funds
- Selecting appropriate fee rates for desired confirmation speed
- Optimising transaction size (e.g., using SegWit) to reduce fees
- Understanding the fee market and mempool dynamics
- Educational foundation of Bitcoin fee structure
Related calculators · Mining & Blockchain
Recently updated formulas
Suggest an improvement
Found a mistake? Have a better example? Let us know.
You may send up to 3 suggestions per 24 hours.