Direct Answer
A satoshi is the smallest unit represented in Bitcoin. Learn the BTC relationship, intermediate units and exact conversion examples.
A satoshi is the smallest whole unit recorded in a Bitcoin transaction output. One bitcoin contains exactly 100,000,000 satoshis, but that fixed relationship is only the starting point. Wallets, payment requests, Lightning invoices, transaction-fee estimates, exchanges, accounting systems, and APIs can all display related numbers that use different units and answer different questions.
A wallet may show 0.00025000 BTC while an invoice shows 25,000 sats. Those values represent the same amount of bitcoin. A value written as 25 sat/vB, however, is a transaction fee rate rather than a balance. A value written as 25,000 msat belongs to Lightning accounting and equals 25 sats, not 25,000 sats.
The practical task is therefore not just memorizing one conversion ratio. It is learning to preserve the unit, recognize whole-satoshi precision, distinguish amounts from fee rates, and confirm that software has not silently changed the value through rounding or formatting.
How many satoshis are in one bitcoin?
One bitcoin contains exactly 100 million satoshis. The relationship is fixed:
1 BTC = 100,000,000 sats
1 sat = 0.00000001 BTC
“Satoshi” is the full unit name. “Sat” is the common singular abbreviation, while “sats” is commonly used for plural amounts. The name honors Satoshi Nakamoto, the pseudonymous author of the Bitcoin white paper.
The ratio does not change with the market price of bitcoin. One sat remains one hundred-millionth of one BTC whether BTC trades higher, lower, or is not assigned a fiat price at all. Market price changes purchasing power. It does not change the denomination.
This distinction separates two different calculations. A denomination conversion answers, “How much bitcoin does this number represent?” A fiat conversion answers, “What is that amount worth at a particular exchange rate and time?” A wallet can update its dollar estimate without changing the satoshi amount.
The integer inside a transaction output
Bitcoin does not store an output amount as a decimal BTC string such as 0.00234567. A transaction output contains an integer value measured in satoshis and a locking script that defines the conditions under which that value can later be spent.
Bitcoin Core defines monetary amounts with an integer type called CAmount and defines one BTC as 100,000,000 satoshis. The documented transaction format likewise represents each output value as an integer number of satoshis.
Suppose a transaction output contains the integer:
234567
That output contains exactly 234,567 sats. A wallet may display the same value as:
- 234,567 sats
- 2,345.67 bits
- 2.34567 mBTC
- 0.00234567 BTC
The presentation changes. The underlying integer does not. This is why two wallets can display different denominations without disagreeing about the amount controlled by the wallet.
It is common to say that Bitcoin supports eight decimal places. A more precise explanation is that one BTC is defined as 100,000,000 integer satoshis. A BTC-formatted interface can therefore display a whole-satoshi amount with up to eight decimal places. The decimal point belongs to the presentation layer, not to the serialized transaction output.
Why eight BTC decimal places matter
Because one BTC equals 100,000,000 sats, eight decimal places in a BTC-formatted amount reach the whole-satoshi boundary:
0.00000001 BTC = 1 sat
A non-zero ninth decimal describes a fractional satoshi. For example:
0.000000015 BTC × 100,000,000
= 1.5 sats
A Bitcoin base-layer transaction output cannot encode 1.5 sats because its value field records a whole integer. Software must reject the value or apply an explicit rounding rule before building the transaction.
Extra trailing zeros do not create extra economic precision. These two strings still represent the same amount:
0.00000001 BTC
0.000000010 BTC
Both equal exactly one sat. The second string contains an additional displayed decimal place, but the ninth digit is zero.
Now compare:
0.000000010 BTC = 1 sat
0.000000011 BTC = 1.1 sats
The first amount is exactly representable on Bitcoin’s base layer. The second is not. The problem is not the number of characters after the decimal point by itself. The problem is a non-zero value beyond whole-satoshi precision.
BTC, mBTC, bits, and sats
BTC, mBTC, bits, and sats are different ways to write the same kind of Bitcoin amount. They are denominations, not separate assets. Changing the denomination changes the placement of the decimal point. It does not move funds, alter ownership, or create a different transaction output.
Fixed unit relationships
| Unit | Value in BTC | Satoshis per unit | Smallest whole-satoshi increment |
|---|---|---|---|
| BTC | 1 BTC | 100,000,000 sats | 0.00000001 BTC |
| mBTC | 0.001 BTC | 100,000 sats | 0.00001 mBTC |
| bit or μBTC | 0.000001 BTC | 100 sats | 0.01 bit |
| sat | 0.00000001 BTC | 1 sat | 1 sat |
A millibitcoin, written mBTC, is one thousandth of one BTC and therefore equals 100,000 sats. A bit, also called a microbitcoin or μBTC, equals 100 sats. BIP 176 describes “bit” as a display denomination rather than a separate asset.
The same 25,000-sat amount can be written as:
- 25,000 sats
- 250 bits
- 0.25 mBTC
- 0.00025 BTC
Nothing was added or removed. Only the unit changed.
Each unit also has a different whole-satoshi precision boundary. A BTC field can represent whole sats with up to eight decimal places. An mBTC field needs no more than five decimal places for whole-satoshi precision. A bit field reaches one sat at two decimal places. A sat field should contain a whole integer when it represents a base-layer amount.
The decimal point is a display choice
A wallet can display a balance in BTC even though the transaction outputs behind that balance contain integer satoshi values. Another wallet may display the same balance in sats. An accounting system may use mBTC, while a small-payment interface may use bits.
BTC is often convenient for larger balances. Sats are easier to verify for small payments and fees because they remove a long string of leading zeros. Bits provide an intermediate scale, although software is not required to offer every denomination.
No display unit is more real than the others. For exact base-layer arithmetic, all of them resolve to one canonical integer number of sats.
Why wallets choose different denominations
Wallet interfaces choose denominations for readability. A value such as 0.00000100 BTC may be easier to recognize as 100 sats. A larger balance may be easier to compare in BTC. The interface may also allow the user to switch units without changing the actual amount.
The unit label must remain visible. A number such as 100000 is incomplete by itself because it could mean 100,000 sats, 100,000 bits, 100,000 mBTC, or 100,000 BTC.
Use the Satoshi Converter when the task is to convert an exact amount among BTC, mBTC, bits, and sats. The converter performs the arithmetic. This guide explains why the units behave the way they do.
Exact conversion without silent rounding
A reliable Bitcoin conversion must preserve the economic amount. It should not accept an overprecise decimal, silently round it, and then present the rounded result as though nothing changed.
Whole-satoshi validation
For BTC input, the core conversion is:
sats = BTC × 100,000,000
For the result to be represented exactly in a Bitcoin base-layer output, the satoshi value must be a whole integer.
| BTC input | Exact satoshi result | Base-layer status |
|---|---|---|
| 0.00000001 BTC | 1 sat | Exact |
| 0.000000010 BTC | 1 sat | Exact; extra trailing zero |
| 0.000000015 BTC | 1.5 sats | Overprecise |
| 0.00234567 BTC | 234,567 sats | Exact |
| 0.002345675 BTC | 234,567.5 sats | Overprecise |
An overprecise result is not the same as an invalid character string. The decimal may be mathematically meaningful, but it cannot become an exact whole-satoshi output without changing the amount.
Overprecision and silent rounding
Consider this input:
0.002345675 BTC
The exact conversion is:
0.002345675 × 100,000,000
= 234,567.5 sats
If software truncates the value, it creates 234,567 sats. If it rounds upward, it creates 234,568 sats. Neither output is identical to the original mathematical amount.
The one-sat difference may be financially small, but the behavior still matters. Deterministic financial software should produce the same result for the same input. Two systems using different hidden rounding rules can disagree. Repeated hidden rounding can also create reconciliation differences across many records.
A clear interface should distinguish among three states:
- Exact: the input converts to a whole number of sats.
- Overprecise: the input requires a fractional satoshi.
- Invalid: the text cannot be parsed as an amount in the selected unit.
Rejecting an overprecise base-layer amount is often clearer than applying a hidden rounding rule. When an application does round, it should identify the rule and show the value after rounding before the user approves the transaction.
Why floating point can change the result
Many decimal fractions cannot be represented exactly with ordinary binary floating-point arithmetic. Software may internally hold a value slightly above or below the decimal text the user entered.
When that approximation is multiplied by 100,000,000 and rounded to an integer, it can cross a whole-satoshi boundary. Most familiar conversions may appear correct, but correctness should not depend on an invisible approximation.
A safer conversion sequence is:
- Read the amount as a decimal string.
- Identify the selected unit.
- Normalize the string without converting it to binary floating point.
- Scale the decimal into integer sats.
- Reject non-zero digits beyond whole-satoshi precision.
- Generate every display unit from the same integer value.
Once the software has a canonical integer number of sats, it can derive BTC, mBTC, and bits without losing the underlying amount. A round-trip conversion can then be tested:
BTC decimal string
→ integer sats
→ BTC decimal string
A correct exact conversion returns the same economic value or clearly rejects the original input as overprecise.
A reproducible conversion example
Take this BTC amount:
0.00234567 BTC
Convert BTC to sats:
0.00234567 × 100,000,000
= 234,567 sats
Convert BTC to mBTC:
0.00234567 × 1,000
= 2.34567 mBTC
Convert sats to bits:
234,567 ÷ 100
= 2,345.67 bits
The four exact representations are therefore:
- 0.00234567 BTC
- 2.34567 mBTC
- 2,345.67 bits
- 234,567 sats
The amount remained unchanged through every step. Each display was derived from the same exact satoshi integer.
Sats in wallets and payment requests
A displayed wallet balance may look like one number, but on-chain bitcoin is represented through transaction outputs. A wallet can control several unspent transaction outputs, usually called UTXOs, and add their satoshi values to display one total balance.
A wallet balance is a sum of UTXOs
A wallet might control three UTXOs:
40,000 sats
75,000 sats
119,567 sats
The displayed balance is:
40,000
+ 75,000
+ 119,567
= 234,567 sats
This wallet controls the same total amount as a wallet holding one 234,567-sat UTXO. The unit conversion is identical, but the future spending structure is not.
Three inputs can produce a larger transaction than one input. That can change virtual size, the network fee, the change-output structure, and privacy implications. Sats describe value. UTXOs describe where that value is locked and how it can be spent.
This explains why two wallets with equal balances can receive different transaction-fee estimates. The balance can be identical in sats while the selected input structure is different.
Bitcoin URI amounts use BTC
A Bitcoin payment request can carry an amount in a bitcoin: URI. BIP 321 specifies the amount parameter in decimal BTC.
bitcoin:<address>?amount=0.001
The amount means:
0.001 BTC
= 100,000 sats
It does not mean 0.001 sat. A wallet may display the parsed payment in sats, but the URI amount itself uses BTC notation.
This creates a copy-and-paste risk. Pasting 100000 from a sat-denominated invoice into a field labeled BTC changes the interpreted amount dramatically. The numeric characters alone are not enough. The unit must travel with the number.
A wallet should show the parsed destination and amount before requesting authorization. The user should still verify the destination, denomination, and final recipient amount shown in the confirmation screen.
One amount across several interfaces
Consider a payment of 234,567 sats. A wallet, URI, fee screen, and Lightning interface may show several related numbers:
| Display | Meaning |
|---|---|
| 0.00234567 BTC | Recipient amount shown in BTC |
| 234,567 sats | The same recipient amount shown in sats |
| 1,410 sats | A possible total on-chain transaction fee |
| 10 sat/vB | The fee rate used to price virtual size |
| 750 msat | A sub-satoshi Lightning amount or routing fee |
All five values can be valid at the same time because they answer different questions. The user must identify whether a label describes the payment amount, total fee, fee rate, or Lightning accounting precision.
Sats, millisatoshis, and sat/vB
The words look related, but sat, msat, and sat/vB are not interchangeable.
Lightning millisatoshis
The Lightning Network uses a finer accounting unit called the millisatoshi, abbreviated msat:
1 sat = 1,000 msat
Lightning protocol messages use millisatoshi-denominated fields for payment amounts, HTLC values, balances, and routing fees. This allows the protocol to calculate values below one whole satoshi inside an off-chain payment route.
For example:
1,500 msat = 1.5 sats
25,000 msat = 25 sats
A value of 1.5 sats can exist in Lightning accounting. It cannot become an independent Bitcoin base-layer transaction output worth 1.5 sats. When channel state is enforced through an on-chain transaction, the relevant transaction rules resolve output values to whole satoshis.
Millisatoshis do not redefine BTC and do not create a new class of base-layer bitcoin. They provide finer off-chain accounting precision while the base layer continues to use whole-satoshi output values.
The unit label remains critical:
25,000 msat = 25 sats
25,000 sats = 25,000,000 msat
Missing the letter m changes the interpretation by a factor of 1,000.
Fee rate versus total fee
A satoshi is an amount. Sat/vB is a fee rate: satoshis per virtual byte.
The simplified fee relationship is:
Total fee in sats
=
Virtual size in vB
×
Fee rate in sat/vB
A 141-vB transaction at 10 sat/vB has a modeled fee of:
141 vB × 10 sat/vB
= 1,410 sats
The transaction fee is 1,410 sats. The fee rate is 10 sat/vB. Writing “10 sats” would describe an amount rather than the rate used to price the transaction.
The amount sent does not determine the fee by itself. A smaller payment can cost more than a larger payment when the smaller payment spends more inputs or creates a larger transaction. Read how Bitcoin transaction fees work for the complete relationship among inputs, outputs, Weight, virtual size, and sat/vB.
Four labels, four different questions
| Label | What it measures | Example |
|---|---|---|
| sat or sats | An amount of bitcoin | 25,000 sats |
| BTC | The same asset at a larger display scale | 0.00025 BTC |
| msat | Lightning sub-satoshi accounting | 25,000 msat = 25 sats |
| sat/vB | An on-chain transaction fee rate | 10 sat/vB |
Compare values only after identifying their units and roles.
The smallest unit is not a spendability test
One sat is the smallest whole amount represented in a Bitcoin base-layer output, but that does not mean every one-sat output is practical to create, relay, or spend.
Policy dust
Dust is not a smaller denomination. It is a node-policy concept connected to an output’s script type and the estimated cost of spending that output.
An output can contain a positive whole-satoshi value and still fall below a node’s dust-related relay threshold. That does not make the amount fractional or invalid under the denomination model. It means the output conflicts with a relay-policy boundary.
Different output types can have different spending costs, which means the relevant dust-policy boundary is not defined by the number of sats alone.
Economic spendability
An output may sit above a policy dust threshold and still cost more to spend than it contains. Future fee rate, input type, and the marginal virtual size added by the input determine that economic comparison.
| Question | What it measures |
|---|---|
| Is the amount a whole number of sats? | Denomination and precision |
| Is the output non-dust? | Relay-policy treatment |
| Is the output worth spending? | Future marginal spending cost |
A denomination guide answers the first question. Use the Bitcoin Dust and UTXO Spendability Calculator for policy and economic-spendability analysis.
This boundary prevents a common mistake: assuming that “one sat is valid” also means “a one-sat UTXO is useful.” The unit can be valid while the output is impractical.
Errors that change the amount
Most serious unit errors do not come from the fixed conversion ratio. They occur when a number loses its label, software silently rounds an overprecise value, or the user confuses the recipient amount with the network fee.
Missing a leading zero
These values differ by a factor of ten:
0.0001 BTC = 10,000 sats
0.00001 BTC = 1,000 sats
Small BTC values contain several leading zeros, which makes visual checking difficult. Converting to sats can make the magnitude easier to verify before the transaction is signed.
Missing or changing the unit
The string 100000 does not identify a complete Bitcoin amount. These are different values:
- 100,000 sats
- 100,000 bits
- 100,000 mBTC
- 100,000 BTC
Copy the unit with the number. Recheck the destination field before pasting.
Mixing the payment and the fee
A wallet can send 100,000 sats and charge a 1,200-sat network fee. The recipient amount and total wallet debit are different:
Recipient amount: 100,000 sats
Network fee: 1,200 sats
Total debit: 101,200 sats
The final debit can also depend on selected inputs and change. Review the recipient amount and fee as separate lines in the wallet confirmation screen.
Copying overprecise values
A value such as 0.000000015 BTC equals 1.5 sats. A base-layer payment system must reject it or disclose an explicit rounding rule. Presenting 1 or 2 sats without explaining the conversion changes the amount silently.
Thousands separators and locale
Human-readable values may contain commas, spaces, or locale-specific decimal separators. Protocol and API fields often use stricter formats. A Bitcoin URI amount, for example, uses decimal BTC notation and a period as the decimal separator.
Do not assume that every system interprets 1,000 as one thousand. One parser may reject it, while another locale may interpret a comma differently. Normalize the input under a documented rule before converting it.
Scientific notation in APIs
Some APIs or spreadsheets may format a small BTC value as scientific notation, such as 1e-8. That expression mathematically equals one sat when interpreted as BTC, but not every wallet or payment field accepts scientific notation.
Convert the value to the explicit decimal or integer-satoshi form before sending it to a system that expects a Bitcoin amount. Do not assume that a valid mathematical expression is also a valid payment-field format.
Using fiat as the source amount
A wallet may display 50,000 sats beside an estimated dollar value. The fiat estimate can change with the provider, timestamp, spread, and display rounding. The 50,000-sat amount remains fixed.
Do not reconstruct the Bitcoin amount by converting a rounded fiat display back into BTC. Use the Bitcoin-denominated amount as the authoritative payment value.
What a satoshi does not tell you
A satoshi amount describes quantity. It does not, by itself, identify:
- the owner of the funds;
- the address or locking script;
- the number or type of UTXOs;
- the transaction’s confirmation state;
- the total network fee;
- the selected fee rate;
- the transaction’s virtual size;
- whether the output is dust;
- whether the output is economical to spend;
- the current fiat value;
- whether the payment is on-chain or Lightning.
Those questions require additional context. The Bitcoin network reference covers the network and transaction context. The fee guide covers virtual size and sat/vB. The Dust calculator covers policy and spending economics.
Keeping those tasks separate prevents a simple denomination answer from becoming an inaccurate conclusion about fees, confirmation, ownership, or spendability.
Before you confirm a Bitcoin amount
Use this sequence whenever BTC, mBTC, bits, sats, or msats appear in a payment workflow:
- Identify whether the payment is on Bitcoin’s base layer or Lightning.
- Read the unit attached to the amount.
- Confirm that the number is the recipient amount rather than a fee or fee rate.
- Convert through the fixed denomination relationship, not through a fiat price.
- Confirm that an on-chain amount resolves to a whole number of sats.
- Look for an explicit rounding, truncation, or minimum-output rule.
- Review the destination, recipient amount, and fee in the final wallet preview.
- Keep the unit attached whenever the amount is copied into another system.
A satoshi is simple to define: it is one hundred-millionth of one bitcoin. Correct use requires one additional habit—never separate the number from its unit label.
Satoshi FAQ
Is a sat the same as a satoshi?
Yes. “Satoshi” is the full unit name, while “sat” and “sats” are common short forms. One sat equals 0.00000001 BTC, and 100,000,000 sats equal one BTC.
Can a Bitcoin output contain less than one satoshi?
No. A Bitcoin base-layer transaction output records an integer number of satoshis. A mathematical value such as 1.5 sats must be rejected or changed through an explicit rounding rule before it can become an output.
Why does Lightning use millisatoshis?
Lightning uses millisatoshis for off-chain accounting and routing-fee calculations below one whole satoshi. One sat equals 1,000 msat. This precision does not change the whole-satoshi format of Bitcoin base-layer outputs.
Is sat/vB a Bitcoin denomination?
No. Sat/vB is a transaction fee rate measured in satoshis per virtual byte. Sats measure an amount of bitcoin, while sat/vB prices the virtual size of an on-chain transaction.
Why do wallets show different units for the same balance?
Wallets can format the same integer satoshi amount as BTC, mBTC, bits, or sats. The display changes, but the underlying whole-satoshi value remains the same.
Technical sources
The unit relationships, transaction-output model, virtual-size terminology, Bitcoin URI behavior, and Lightning accounting boundaries in this guide are based on the following primary technical references.
Sources
Found an error? Report a content issue or read our Corrections Policy.