Skip to main content
Yoryantra
Home/Tools
← Back to Tools

Base32 Encoder Decoder

Encode bytes with RFC 4648 Base32 or decode padded and unpadded values safely.

Encode normal text or hex bytes to Base32, or decode Base32 back to text, hex, or byte values.

Options

Base32 is commonly used for secrets, OTP setup strings, compact tokens, and systems where uppercase letters and digits are easier to handle.

Output

Converted Base32 output will appear here.
Conversion runs in your browser. Yoryantra does not send the value to a conversion API. Base32 is not encryption, so treat decoded secrets as sensitive data.

Base32 is a byte encoding, not a text format

RFC 4648 Base32 turns every five input bits into one character from A-Z and 2-7. That makes arbitrary bytes easier to copy through systems that prefer letters and digits, at the cost of producing more characters than Base64.

Text input is encoded as UTF-8 bytes first. Hex input represents the bytes directly. On decode, choose hex or byte output when the payload is binary; text output deliberately rejects byte sequences that are not valid UTF-8 instead of hiding corruption behind replacement characters.

Padding has a shape, not just a trailing equals sign

Standard Base32 works in eight-character output quanta. Depending on the final byte count, a padded value can end with six, four, three, one, or zero equals signs. A decoder should not accept arbitrary padding or impossible data lengths because different malformed strings could otherwise appear to represent the same bytes.

Unpadded Base32 is used by some surrounding protocols. When padding is omitted here, the decoder still checks that the remaining symbol count is possible and that unused pad bits are zero. RFC 4648 requires padding by default unless the specification using Base32 says otherwise.

RFC 4648 Base32

Uses A-Z followed by 2-7. Uppercase is the canonical alphabet shown in RFC 4648; lowercase acceptance here is an explicit compatibility option and is reported as a normalization.

Base32hex

Uses 0-9 followed by A-V. It carries the same five-bit values but in a different symbol order, so decoding with the wrong alphabet produces the wrong bytes or a validation error.

TOTP secrets need a different kind of caution

Authenticator setup secrets are often displayed as unpadded Base32, but Base32 itself provides no confidentiality or integrity. Decoding a TOTP secret reveals the original secret bytes; it does not verify a one-time password and it does not tell you whether the secret is safe to disclose.

Avoid pasting production authentication seeds unless you genuinely need to inspect them. Browser-local processing reduces network exposure, but clipboard history, screen capture, extensions, and the device itself can still expose a secret.

Where decoding is intentionally strict

  • Characters outside the selected alphabet are rejected.
  • Padding may appear only at the end and must use a valid count.
  • Impossible unpadded lengths such as one, three, or six symbols modulo eight are rejected.
  • Non-zero unused pad bits are rejected to preserve canonical byte interpretation.
  • Whitespace and lowercase letters are accepted only when their compatibility options are enabled.

A small byte-level example

UTF-8 text: hello
Hex bytes:  68656c6c6f
Base32:     NBSWY3DP

The encoded value is a representation of the five bytes, not a hash or encryption result. Decoding NBSWY3DP returns those same bytes.

Reference behind the alphabet and padding rules

RFC 4648 defines Base32, Base32hex, padding, treatment of non-alphabet characters, and canonical pad-bit requirements. Protocol-specific formats may add stricter or different rules on top of it.