Cosmos Address Converter – Change Bech32 Prefix (cosmos1, osmo1…)

What is a Cosmos address converter?

A Cosmos address converter decodes a bech32 address from any Cosmos SDK chain into its raw account bytes (20 bytes for wallets, 32 for module and contract accounts) and re-encodes those bytes with a different human-readable prefix. Cosmos SDK chains all use the same encoding, described in the Cosmos SDK accounts documentation: prefix, the separator 1, the data in bech32's 32-character alphabet, and a six-character checksum. Only the prefix changes between chains, so cosmos1…, osmo1… and juno1… addresses with the same bytes belong to the same key.

How the conversion works

Verify the bech32 checksum over the whole string, including the prefix. The tool uses the same polymod as SegWit addresses, with the bech32 constant 1 (Cosmos does not use bech32m).
Convert the 5-bit data groups back to bytes with no padding allowed, and require 20 or 32 bytes.
For every prefix in the table, regroup the bytes into 5-bit values and compute a fresh checksum with that prefix.

Worked example

The address cosmos15c20sqakl4uqnp4y93uwe8rlwlnda5futtjxsl decodes to the 20 bytes 0xa614f803b6fd780986a42c78ec9c7f77e6ded13c. Re-encoding those bytes with the Osmosis prefix produces an osmo1… address with the same 32 data characters and a different six-character checksum, because the prefix is part of the checksum input. The 0x form, EIP-55 checksummed, is what an EVM-compatible chain would display for the same bytes.

Prefixes in the table

Prefix	Chain	Key derivation	Prefix	Chain	Key derivation
cosmos	Cosmos Hub	secp256k1	celestia	Celestia	secp256k1
osmo	Osmosis	secp256k1	dydx	dYdX Chain	secp256k1
juno	Juno	secp256k1	noble	Noble	secp256k1
stars	Stargaze	secp256k1	neutron	Neutron	secp256k1
akash	Akash	secp256k1	stride	Stride	secp256k1
kava	Kava	secp256k1	evmos	Evmos	ethsecp256k1
secret	Secret Network	secp256k1	cre	Crescent	secp256k1
axelar	Axelar	secp256k1	regen	Regen	secp256k1
inj	Injective	ethsecp256k1	terra	Terra	secp256k1
sei	Sei	secp256k1 (EVM address linked on-chain)	kujira	Kujira	secp256k1

An address with a prefix outside this list is still decoded and shown at the top of the table under its own prefix.

When the converted address is yours, and when it is not

Wallets such as Keplr and Leap derive one key per chain from your mnemonic. For chains that share the standard coin type 118 and secp256k1 derivation, the derived address on each chain is exactly the re-encoded one, which is why IBC transfers to "your own address on the other chain" work. Chains with coin type 60 and Ethereum-style keys (Injective, Evmos) derive different bytes, and Sei links a separate EVM address to the sei1 account through an on-chain association rather than sharing bytes. Before sending to a converted address, confirm it in the wallet for that chain.

Typical uses

Finding your Osmosis or Celestia deposit address from a Cosmos Hub address when a wallet only shows one chain.
Turning a MetaMask 0x address into the inj1… or evmos1… form an exchange withdrawal form expects.
Checking that a valoper address was not pasted where an account address belongs.

For raw bech32 strings with arbitrary prefixes use the bech32 encoder / decoder; to verify an EIP-55 form use the Ethereum checksum converter.

Frequently asked questions

Are cosmos1… and osmo1… addresses the same account?

They hold the same 20 bytes, and for chains that use the standard secp256k1 derivation the same mnemonic produces both. But each chain is a separate ledger: tokens on Osmosis sit under the osmo1 address, tokens on Cosmos Hub under cosmos1. Re-encoding does not move anything; it only tells you what your address looks like elsewhere.

Why does my Injective or Evmos address not match the converted row?

Injective, Evmos and other ethsecp256k1 chains derive the account bytes like Ethereum (keccak-256 of the uncompressed public key), while most Cosmos chains use sha256 then ripemd160 of the compressed key. The same mnemonic therefore gives different bytes on the two families. The converter re-encodes whatever bytes you paste, so an inj1 address converted to cosmos1 is a valid string but not the address your wallet shows for Cosmos Hub.

What is the 0x form good for?

On Injective and Evmos the 0x form is the account's Ethereum address, used by MetaMask and EVM tooling. On other chains it is just the raw bytes, useful for debugging and for module-account lookups. The tool shows it EIP-55 checksummed.

What are valoper and valcons addresses?

cosmosvaloper1… is a validator's operator address, the same 20 bytes as the operator's wallet under a different prefix; cosmosvalcons1… is the hash of the validator's consensus key. Neither can receive tokens. The converter recognises both and, for valoper, shows the matching account address.

Why is my address 59 characters long?

That is a 32-byte address: module accounts, interchain accounts and CosmWasm contract addresses are sha256-derived and longer than wallet addresses. The tool decodes them and re-encodes under other prefixes, but such an account only exists on the chain that created it.

Does the tool check the bech32 checksum?

Yes. Cosmos addresses use the original bech32 checksum from BIP-173 (not bech32m), and the tool verifies it before converting. A failed checksum means a typo; a bech32m checksum means the string is a Taproot address or similar, not a Cosmos address.