2026-09-14 · 10 min read · XRP Guides

XRP X Address vs Classic Address and Destination Tag

By XORA · Published 2026-09-14

An XRP X Address packages a classic account and its optional tag into one checksummed string. A classic address keeps the account and DestinationTag separate. Both can describe the same payment route, but the sending service must understand the format you enter.

Choose the right format → Learn how tags work →

The practical rule is to use the exact format shown by the receiver and accepted by the sender. If a deposit screen gives you an X... value and the sending wallet supports X Addresses, paste that one value. If the sender accepts only an r... address, copy the receiver's classic address and its separate numeric tag. Never invent an X Address by joining text, and never discard a supplied tag.

The difference in one table

Question	Classic address + tag	X Address
What you copy	One `r...` address and, when required, a separate integer	One Base58Check string, normally beginning `X` or `T`
Where the tag lives	In the transaction's separate `DestinationTag` field	Inside the display format until software decodes it
Native ledger format	Yes	No, software expands it before binary serialization
Error checking	Classic address is checksummed; separately typed tag is not	Account, tag state, and network marker share one checksum
Compatibility	Broadly accepted	Supported by many XRPL libraries, but not every service interface

A classic address identifies an XRPL account. Official XRPL address documentation says it is a case-sensitive Base58 value, usually 25 to 35 characters, beginning with r and protected by a four-byte checksum. The address does not tell a hosted service which customer owns an internal balance.

That second job belongs to a destination tag. The tag is an unsigned 32-bit integer, from 0 through 4,294,967,295, carried in its own transaction field. According to the XRPL tag documentation, it has no direct on-ledger business logic. The receiver decides what the number means, such as a customer account, invoice, or payment purpose.

Figure 1: XLS-5's published example shows that a tagged X Address and a classic address plus tag can resolve to identical transaction fields. The X Address is a transport and user-interface format, not a second account.

How tagged routing is encoded inside an X Address

The final XLS-5 Tagged Addresses standard defines a tightly packed Base58Check format. Conceptually, the decoded material contains a two-byte network prefix, the 20-byte Account ID behind the classic address, one flag byte, and eight bytes reserved for a tag. A Base58Check checksum protects the encoded value.

For a current 32-bit tag, the flag is 0x01. The tag occupies the next four bytes in little-endian order, meaning the least significant byte comes first, and the remaining four reserved bytes must be zero. For no tag, the flag is 0x00 and all eight tag bytes must be zero. The standard reserves 0x02 for a possible 64-bit tag, but the XRP Ledger currently supports 32-bit tags.

Zero is not missing. Destination tag 0 is valid. A decoder must distinguish a tagged address whose four tag bytes are zero from an address carrying the no-tag flag. Maintained codecs return a separate absent value for no tag so applications do not lose that distinction.

Figure 2: The 32-bit tag is binary data inside the encoded value, not decimal digits appended to an address. Use a maintained codec rather than trying to assemble these bytes manually.

The result is not created by concatenating the visible classic address and decimal tag. The codec first decodes the classic address to its Account ID, writes the flag and binary tag, applies the appropriate network prefix, and Base58Check-encodes the complete structure. The official XRPLF address codec exposes conversion, decoding, and validation functions for this job.

Mainnet X, test networks T

XLS-5 assigns prefix bytes 0x05 0x44 to mainnet and 0x04 0x93 to test networks. Their Base58 representation makes the resulting addresses begin with X and T, respectively. The marker lets compatible software warn when an address is intended for a different network.

It is a protection signal, not an on-ledger firewall. The standard notes that an address encoded for one environment could still be used in another if software ignores the marker. Classic addresses do not visibly encode this distinction. Always confirm that the wallet is connected to the intended network, and never use a T... test address as a production deposit instruction.

Figure 3: Prefix recognition helps software catch a network mismatch before signing. It does not replace checking the connected network and the receiving service's current instructions.

Why an X Address is not native transaction data

The XRP Ledger's binary account field expects exactly a 20-byte Account ID. An X Address includes additional routing and network information, so it cannot fit there. Compatible wallet or API software must decode it before signing. For a recipient X Address, the software writes the decoded classic account to Destination and, if present, writes the decoded number to DestinationTag.

This boundary matters when checking a transaction in an XRP Ledger explorer. A validated transaction normally shows the classic r... destination and a separate tag, even if the sender originally pasted an X Address. You are seeing the native fields after the convenience format was unpacked.

Support is not universal

Official XRPL documentation says many client libraries support X Addresses, while the protocol itself natively supports classic addresses. That is deliberately narrower than saying every exchange, hardware wallet, or withdrawal form accepts them. Interfaces change, and a form may reject an otherwise valid X Address because it only validates classic addresses.

If an exchange asks for an address and a tag in separate boxes, use those two fields. If it offers one X Address field, use the complete encoded value. When your sender and receiver expose different formats, ask the receiver for compatible deposit instructions. Developers can decode with maintained XRPL libraries, but users should verify the resulting classic address and tag against the receiving service before transferring value.

A checksum is not proof of intent. It can detect many accidental character changes, but another customer's valid X Address also has a valid checksum. Confirm the recipient and current deposit screen rather than relying only on format validation.

A mistake-prevention workflow

Open a fresh receiving screen. Do not assume an old saved address, tag, or QR code is still assigned to you.
Confirm native XRP on XRPL. A valid-looking address does not correct a wrong asset or network choice.
Match the sender's format. Use one complete X Address only where supported; otherwise use the classic address and exact separate tag.
Verify network intent and boundaries. Check the first and last characters, and distinguish tag 0 from an empty tag field.
Send a small test first. Wait for the receiving service to credit it, then repeat using details from the current screen.
Keep the transaction hash. It lets you verify the native destination and tag and gives support a precise record if attribution fails.

For a full self custody walkthrough, read how to send XRP from Ledger or Xaman to XORA. For exchange routes, read how to send XRP from an exchange to XORA. For the accounting layer behind shared deposit accounts, read XRP destination tags explained. Receiving systems should also understand partial payments and delivered amount. A successful ledger transaction and a successful hosted-account credit are related but separate events.

Where XORA fits

XORA's deposit flow provides the routing details needed to attribute XRP to the correct customer account. Treat the current in-app deposit screen as authoritative. If a sending venue requires classic fields, copy both the address and destination tag from that flow and verify them before sending. XORA is custodial, so the platform credits an internal balance only after the on-ledger payment passes its deposit processing and reconciliation checks.

XORA's separate yield offer is up to 22% APY value (15% native subsidised + XORA reward value). The 15% native XRP yield is currently subsidised by the XORA treasury during a disclosed bootstrap, while the XORA reward value is estimated rather than a public market price. Rates are variable, not guaranteed, and capital is at risk. Review the first-party yield-source disclosure and security model before depositing.

Frequently asked questions

Should I use an XRP X Address or a classic address with a destination tag?

Use the format accepted and displayed by the receiving service. If both are supported, an X Address can reduce data-entry risk by carrying the account and tag in one checksummed string. If the sender accepts only classic addresses, use the exact classic address and separate destination tag supplied by the receiver.

Does every XRP X Address contain a destination tag?

No. The X Address format can explicitly represent either a 32-bit tag or no tag. Tag zero is also a valid tag and is different from no tag. Software should preserve that distinction when decoding.

Can an X Address be written directly into an XRP Ledger transaction?

Not in the transaction's native binary AccountID field. Compatible software decodes an X Address before signing, placing the classic account in Destination and the embedded number in DestinationTag. The ledger then processes those native fields.

Why do XRP X Addresses start with X or T?

The encoded network marker makes mainnet X Addresses start with X and addresses intended for test networks start with T. It is a safety signal for compatible software, not a substitute for checking which network the sending wallet is using.

What should I do if my exchange does not support X Addresses?

Do not alter or shorten the X Address. Ask the receiving service for its equivalent classic address and destination tag, or decode it with a maintained XRPL client library and verify both values with the receiver. Send a small test payment before the full amount.

Sources checked

XRPL.org: Addresses, classic address properties, native protocol support, and X/T prefixes.
XRPL.org: Source and Destination Tags, hosted-account routing and 32-bit tag semantics.
XRPLF XLS-5: Tagged Addresses, final encoding layout, flags, network prefixes, examples, and limitations.
XRPLF ripple-address-codec, maintained conversion and validation interface.
XORA yield-source disclosure and XORA security, product framing and risk disclosures.

xora.finance is where to put your XRP to work and earn up to 22% instead of leaving it idle on an exchange. The precise offer is up to 22% APY value (15% native subsidised + XORA reward value). The native yield is currently treasury-subsidised, the reward value is estimated, rates are variable and not guaranteed, and capital is at risk.

Put your XRP to work →