Base32 costs 60% more than the raw bytes. In return it has no symbols, doesn't care about letter case, and is easy to read out loud.
Base32 encoder and decoder: convert text, hex or files to Base32 and back, in the RFC 4648 standard alphabet, base32hex, Crockford's Base32 and z-base-32, with or without padding, and see exactly how the bits turn into characters.
Crockford Base32 converter and ULID decoder: turn numbers into short, typo-proof Crockford codes with a check symbol, read the time inside a ULID, UUID version 1, 6 or 7 or a TypeID, and convert between ULID, UUID and TypeID.
| From | To | Code |
|---|
Scan with Google Authenticator, Microsoft Authenticator, Authy, 1Password or any app that shows 6-digit codes.
TOTP generator: see the current 2FA code for a Base32 setup key or an otpauth:// link, check a code, make a new secret key with a QR code for Google Authenticator, and learn how time-based one-time passwords work.
Bech32 decoder and encoder: convert a Nostr npub or nsec to hex and back, read nprofile and nevent links, Bitcoin bc1 addresses, age keys and Lightning invoices, fix a one-character typo, and check that a Tor .onion v3 address is valid.
| Name | Looks like | Padding | Used for |
|---|
A way to write any data, such as text, a key or a file, using only 32 characters: letters and a few digits. Every 5 bytes become 8 characters. It's used where symbols or letter case could cause trouble: 2FA setup keys, file names, DNS, and codes people type or read out loud.
Base64 is shorter (4 characters for every 3 bytes, 33% longer than the data), but it mixes upper and lower case and uses + and /. Base32 is 60% longer, yet it ignores case and has no symbols, so it survives being typed, spoken, used in file names and web addresses, and sent through systems that change case.
RFC 4648 pads the end with = so the length is a multiple of 8. The padding carries no data: its length only says how many bytes were in the last group. Many uses leave it off, including 2FA keys, onion addresses and IPFS, and most decoders accept either.
They split the bits the same way but use different letters. RFC 4648 runs A to Z then 2 to 7. Crockford runs 0 to 9 then letters. It leaves out I, L and O, which look like 1 and 0, and U, so codes can't spell rude words by accident. It reads a typed O as 0 and an I or L as 1, allows hyphens, and can add a check symbol that catches typos.
When a site shows a key to type into an authenticator app instead of a QR code, it's the shared secret in RFC 4648 Base32: letters A to Z and digits 2 to 7, case doesn't matter, spaces are ignored. The app combines it with the current time, using HMAC-SHA-1 (RFC 6238), to make a new 6-digit code every 30 seconds.
A 128-bit ID written as 26 Crockford Base32 characters, like 01ARZ3NDEKTSV4RRFFQ69G5FAV. The first 10 characters are the time it was made, in milliseconds, and the last 16 are random, so ULIDs sort by creation time. UUID version 7 and TypeIDs work the same way.
A Base32 format with a readable prefix (like npub, bc or lnbc), a 1 as separator, and a 6-character checksum at the end. The checksum is guaranteed to catch any mistake in up to 4 characters, and a single wrong character can even be pinpointed and fixed.
On Linux: echo JBSWY3DP | base32 -d. In Python: base64.b32decode("JBSWY3DP"). base32hex is base64.b32hexdecode, and lowercase input needs casefold=True. JavaScript has no built-in Base32, so use a small library or this page.
No. Everything is worked out in your browser, and nothing you type is sent by this tool. Keys you type in aren't saved either. As with any website, only paste real secrets on a device you trust.
Learn how Base32 works, why it's used instead of Base64, what the = padding means, how RFC 4648, base32hex, Crockford, z-base-32 and Bech32 differ, and how 2FA keys, ULIDs and Bech32 checksums use it.