Why not just divide by 1e9 in JavaScript?

A JavaScript number is a 64-bit float with 53 bits of integer precision. Balances above about 9,007,199,254,740,992 nanoton (about 9 million GRAM) lose their last digits, and decimal fractions like 0.1 are not representable at all. This tool keeps everything as BigInt and decimal strings, so the result is exact at any size.

What does the precision error mean?

You typed more decimal places than the unit has. 0.0000000001 GRAM is a tenth of a nanoton, which does not exist on chain; the tool refuses rather than silently rounding, because a rounded amount in a transaction is a wrong amount.

Free tools

Nanoton ↔ GRAM (TON) and jetton units converter

Exact conversion between human amounts and the integer base units the chain actually uses: nanoton for GRAM (formerly Toncoin, 9 decimals) and raw units for jettons with any number of decimals. BigInt arithmetic, no floating point, no rounding.

GRAM (TON) ↔ nanoton

GRAM (formerly Toncoin)

nanoton

Jetton amount ↔ raw units

Preset

Decimals

Amount

Raw units

Runs in your browser. Nothing you paste leaves this page.

Nanoton, GRAM and nine decimals

Every amount on TON is an integer. A liteserver, an API or a get-method never returns "1.5 GRAM"; it returns 1500000000, the number of nanoton, and the client decides how to display it. One GRAM — the renamed native coin of TON, formerly called Toncoin; the network itself is still TON — is 10⁹ nanoton, so the display amount is the integer with the decimal point moved nine places to the left:

Text

1 GRAM          = 1 000 000 000 nanoton
0.000000001 GRAM = 1 nanoton
1e9 GRAM         = 1 000 000 000 000 000 000 nanoton

The converter does exactly that and nothing else: it moves a decimal point. There is no exchange rate here and no on-chain lookup.

Why the tool refuses to use floats

A JavaScript number is a 64-bit float. It represents integers exactly only up to 2⁵³, about 9.007 × 10¹⁵ — roughly 9 million GRAM in nanoton — and it cannot represent most decimal fractions at all: 0.1 + 0.2 is 0.30000000000000004. Dividing a balance by 1e9 and multiplying it back is therefore a lossy round trip, and an amount that is off by one nanoton is still a wrong amount in a transaction.

Everything on this page is BigInt arithmetic on decimal strings. A value that cannot be represented in the unit's decimals — 0.0000000001 GRAM, a tenth of a nanoton — is an error, never a rounding. Scientific notation is handled the same way: 1e9 is one billion, 2.5e-3 is 0.0025, both exact.

Jettons and decimals

A jetton amount is also an integer, in the jetton's own base unit. How many base units make one display unit is the jetton's decimals, published in its metadata — the content cell returned by the master contract's get_jetton_data get-method — under the key decimals. When the key is absent the standard (TEP-64) says 9.

USDT on TON uses 6, like USDT on other chains: 1 USDT is 1000000 raw units. Sending 1000000000 because you assumed nine decimals sends 1,000 USDT, which is the single most common unit mistake on the network. The presets cover USDT and the generic nine; the decimals field takes any value from 0 to 30 for a jetton you are looking at.

This version does not read decimals from the chain. If you do not know them, read the jetton's metadata through a liteserver or an explorer before you trust a number here.

Input the converter accepts

Digits with one decimal point or one decimal comma (1,5), thousands separators as spaces, underscores or commas when a point is present (1 000.25, 1,000,000.5), a leading +, and an exponent (1e9, 2.5E-3). Negative amounts are refused. The output is the plain integer or decimal, plus a grouped version for reading.

Frequently asked questions

How many nanoton are in one GRAM?: One billion: 1 GRAM = 1,000,000,000 nanoton (10^9). GRAM is the renamed native coin of TON, formerly called Toncoin; the network itself is still TON. Every value a node or an API returns is an integer in nanoton.
Why not just divide by 1e9 in JavaScript?: A JavaScript number is a 64-bit float with 53 bits of integer precision. Balances above about 9,007,199,254,740,992 nanoton (about 9 million GRAM) lose their last digits, and decimal fractions like 0.1 are not representable at all. This tool keeps everything as BigInt and decimal strings, so the result is exact at any size.
Where do I find a jetton's decimals?: In the jetton's metadata, the content cell returned by the master contract's get_jetton_data get-method, under the key decimals. When the key is absent the standard says 9. USDT on TON uses 6, which is why 1 USDT is 1,000,000 raw units, not 1,000,000,000.
What does the precision error mean?: You typed more decimal places than the unit has. 0.0000000001 GRAM is a tenth of a nanoton, which does not exist on chain; the tool refuses rather than silently rounding, because a rounded amount in a transaction is a wrong amount.

Private liteserver accessLitenode and Archive plans: query the chain directly with your own key.LiteServers documentationEvery method, rate limits, archive routing and the full error chapter.

More tools

TON liteserver error codes403, 429, 502, -400, 651, 652, -503: cause and fix for every liteserver error, searchable.TON address converter and validatorRaw ↔ EQ ↔ UQ, mainnet and testnet, checksum check, batch mode.TON message hash from a BoCcell_hash, TEP-467 norm_hash and sha256 of any message BoC, hex and base64.