Address Format
Ways of writing a TON contract address: raw (0:hash), friendly base64 (EQ.../UQ...), or a ton:// URI. Each form serves a different purpose.
Aliases: ton address forms, address forms
Address Format refers to the multiple ways a TON contract address can be written. Unlike Ethereum, where an address is just 0x plus 40 hex characters, TON has several representations, each with its own role.
Main formats
| Format | Example | Where you see it |
|---|---|---|
| Raw | 0:abc… | APIs, SDKs, debugging |
| Friendly bounceable | EQ… | Wallets, dApp UI — the default |
| Friendly non-bounceable | UQ… | Addresses for fresh wallets |
| Friendly testnet | kQ… / 0Q… | Test networks |
| TON URI | ton://transfer/EQ…?amount=… | Deep links, QR codes |
All of them encode the same object — the pair (workchain, hash). They differ in optional flags and the presence of a CRC check.
Which one to use
- Storing the address in code or DB — raw. Universal, no ambiguity.
- Showing it to users — friendly, picking bounceable vs non-bounceable based on the target’s deployment status.
- Building a “send” link — TON URI. Wallets open from deep links with the form pre-filled.
- Passing between services — typically friendly, but pick a form and stick to it: the same address in
EQandUQare different strings.
Conversion
Every major SDK converts between forms:
import { Address } from '@ton/core';
const addr = Address.parse('EQAbc…');
addr.toRawString(); // 0:abc…
addr.toString({ bounceable: false }); // UQ…Explorers (TonViewer, TonScan) display all forms on a contract page — handy for debugging. The main rule: don’t mix forms inside one system — that’s a classic integration bug.