Base32 Encode/Decode

Encode text to Base32 (RFC 4648) or decode it back.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Base32 writes bytes using only the 26 capital letters and the digits 2 to 7 — the RFC 4648 alphabet, which has no 0, 1 or 8 to be mistaken for O, I or B — and this tool encodes text into that alphabet or decodes it back.

How to use it

1Press Encode or Decode; Encode is the mode the page opens in.
2Type or paste into the single input box — the result appears underneath as you type.
3Copy the output with the button below it.

Example

Input: Hi
Output: JBUQ====

Output is always padded up to a multiple of eight characters, so two bytes leave four = signs. Going the other way, padding is optional and case does not matter: jbuq decodes to Hi just as well.

What happens to your data

The conversion is plain bit arithmetic performed in the page — five-bit groups shifted out of your bytes — with no library and no request behind it. Decoding runs the bytes through a strict UTF-8 decoder, so input that is not valid text fails with an error in your own tab instead of being sent somewhere to be identified.

Last updated August 2026

Someone has handed you a run of capital letters and digits ending in equals signs — off a two-factor setup screen, out of a DNS record, in a config file — and you want to know what is inside before you act on it. Or you are going the other way: a field will only accept characters that survive being read aloud, written on a whiteboard and typed back in, and base32 is the shape that fits.

Settle which base32 you are holding first, because several alphabets share the name and are not interchangeable. RFC 4648 — the twenty-six capitals plus 2 to 7 — is what this page reads and writes. Crockford base32, the encoding inside a ULID, keeps the digits 0, 1, 8 and 9 and throws out I, L, O and U instead. Base32hex reorders the symbols so sorting the text sorts the bytes; z-base-32 shuffles them again for readability. A string in any of those either stops here with an error naming the character that does not belong, or decodes to bytes that are quietly wrong.

The second thing to settle is whether the encoded bytes are text at all. Base32 spells bytes and does not care what they mean; much of what turns up in it is random key material rather than words. Decoding here ends in a strict UTF-8 check, so a twenty-byte shared secret will not become anything readable however well formed the string is. That is the nature of the data rather than a fault in it, and it is where most people wrongly conclude their string is broken.

How it works

Toolvore reads what you type as UTF-8 bytes and shifts them out five bits at a time, each group of five picking one letter or digit from the alphabet; a short final group is topped up with zero bits, then the text is padded with equals signs to a multiple of eight characters. Decoding runs the same arithmetic backwards after tidying the input: the string is uppercased, and whitespace and equals signs are stripped wherever they appear, so a value broken across several lines pastes in without editing. Anything left that is not in the alphabet stops the job, and the offending character is named back to you. Trailing bits that do not complete a byte are discarded rather than guessed at. The weak point is that this is text in and text out — no file input, no download, no hex or byte view — so bytes that are not valid UTF-8 have nowhere to go except an error. One habit worth knowing: the single box is shared by both modes, so switching from Encode to Decode leaves your text there to be re-read as base32 — usually an error until you clear it.

Common use cases

Encoding an identifier for a case-insensitive filename or DNS label
Checking a string is valid RFC 4648 base32 before your code sees it
Reading a base32 value out of a config file or log line
Producing a code someone has to read over the phone
Comparing your own encoder output against a known-good result
Working out which base32 variant a library was handed

Frequently asked questions

Where is base32 actually used, given base64 is more common?＋

Wherever the alphabet matters more than the size. Authenticator secrets are shared in it because a person has to read one off a screen and type it into a phone. DNS uses it in NSEC3 records, since labels are case-insensitive and a case-sensitive encoding would collapse. Systems that must survive case-folding filesystems, or that print codes on paper for people to copy, reach for it for the same reason. It also survives being spoken aloud, which is why recovery keys and device identifiers often end up in it.

Base32 or base64 — which should I use?＋

Base64 if the value only ever travels between machines, base32 if a human, a filesystem or a case-insensitive protocol is in the path. The cost is size: base32 spends eight characters on every five bytes, so it grows the data by three fifths, where base64 spends four characters on three bytes and grows it by a third. In exchange you get an alphabet with no lowercase to lose, no punctuation to escape and no pairs confused by eye. Over a long attachment that gap is real; over a sixteen-byte key nobody notices.

Is base32 encryption?＋

No, and treating it as such is the expensive mistake. It is a transcription — every byte is recoverable by anyone who recognises the alphabet, with no key involved, and the string only looks scrambled because it is unfamiliar. A secret encoded in base32 is still a secret in plain sight: the seed printed under a two-factor QR code is the whole credential, not a hint of it. Encode to get a value through a channel that cannot carry raw bytes, but if the contents need protecting, encrypt them first and encode the ciphertext.

Why does my base32 string fail with an invalid character?＋

Almost always because it is not RFC 4648 base32, or because a character was mistyped as its look-alike. The digits 0, 1, 8 and 9 are not in this alphabet, so a string containing them belongs to Crockford or another variant. Lowercase l against the digit 1, capital O against 0, and B against 8 are the classic slips when a code is copied off paper. A string with dots in it is something structured — a JWT, for instance. The error names the character it choked on, which usually points at which happened.

Can I decode a two-factor secret to see what is inside it?＋

You can decode it, but there is nothing to read. A TOTP seed is random bytes chosen by the server, not a word or an identifier, so converting it back gives arbitrary byte values that almost never form valid text — and a decoder that insists on valid UTF-8, as this one does, reports an error instead. That error tells you the string was well formed and the contents are not text. If you need the raw bytes for a signing routine, decode them in the language you are writing in.

Does case matter in base32?＋

The standard alphabet is uppercase and encoders emit uppercase, but decoders are conventionally forgiving — this one uppercases the input before it looks at anything, so a value stored in lowercase decodes the same as its capital form. That tolerance is why the encoding gets chosen for DNS labels and for filesystems that fold case: nothing is lost when something in the middle changes it. Do not rely on it in the other direction. Some strict parsers reject lowercase outright, so send uppercase to any system you do not control.

What happens to accented letters and emoji?＋

They encode fine, because the text becomes UTF-8 bytes first and base32 works on bytes rather than characters. The consequence is that non-ASCII text costs more than it looks like it should: a plain letter is one byte, an accented one usually two and an emoji four, before the eight-characters-per-five-bytes expansion applies on top. Round-tripping is faithful as long as both ends agree the bytes are UTF-8. If decoded text comes back as mojibake, the encoder at the other end used a different character set, and re-decoding will not repair it.

Does anything I paste leave my browser?＋

No. The conversion is arithmetic on numbers your browser already has — bit shifts and a thirty-two symbol lookup table — with no upload step and no request behind it, so there is nowhere for the input to be sent even in principle. That matters more here than for most encodings, because the strings people bring to a base32 page are disproportionately recovery keys and authenticator seeds. Nothing is kept, either: the output is recomputed from the box on every keystroke, and closing the tab is enough to be rid of it.