Base32 Encoder/Decoder - RFC 4648, Crockford & Base32hex

How to use this tool

Choose a conversion mode and alphabet. Select Encode or Decode, then choose RFC 4648, Base32hex, or Crockford to match the format expected by the system receiving the result.
Choose text or byte input/output. Encoding accepts UTF-8 text or hexadecimal bytes. Decoding can show UTF-8 text or space-separated hexadecimal bytes for binary values such as TOTP seeds.
Enter a value and review the live result. Type or paste the value. The tool converts it in your browser as you edit; grouped Base32 values may include spaces or hyphens.
Copy or swap the result. Copy the output, or use Swap to feed it back through the opposite mode. Padding can be enabled or omitted while encoding.

What is Base32?

Base32 is a binary-to-text encoding scheme that represents arbitrary binary data as a sequence of printable ASCII characters. It uses an alphabet of 32 characters, making it case-insensitive and safe for use in URLs, file names, and DNS entries.

Compared to Base64, Base32 produces ~60% more characters but avoids characters that are easy to confuse when typed by humans (such as 0/O or 1/I/l in the Crockford variant).

Variants supported

Variant	Alphabet	Common use
RFC 4648 (Standard)	`A–Z, 2–7`	TOTP/2FA secrets, IPFS content IDs
RFC 4648 Base32hex	`0–9, A–V`	NSEC3 DNS records, sortable IDs
Crockford Base32	`0–9, A–Z` (minus I, L, O, U)	Human-readable serial numbers

Encoding efficiency

Every 5 bytes of input produces 8 Base32 characters (a 60% size increase). Padding (=) is added to make the output a multiple of 8 characters. Padding can be omitted when the length is known by context.

Base32 vs Base64

Feature	Base32	Base64
Alphabet size	32 chars	64 chars
Output size	+60%	+33%
Case-insensitive	Yes	No
URL-safe	Yes	Needs variant
Human typeable	Better	Harder

Base32 in TOTP / two-factor authentication

Base32 (RFC 4648 standard variant) is the encoding format used for all TOTP secrets - the seeds shared between authenticator apps (Google Authenticator, Authy, 1Password) and services. When you scan a QR code to add an account, the QR code contains a URI like:

otpauth://totp/Example:user@example.com?secret=JBSWY3DPEB3W64TMMQ&issuer=Example

The secret parameter is a Base32-encoded 20-byte (160-bit) random seed. Base32 is chosen because:

It is case-insensitive (users can type it without worrying about case)
It avoids visually ambiguous characters (no 0/O or 1/I/l confusion in Crockford variant)
It can be typed by hand for manual account setup without a QR scanner

Encoding worked example

Encoding the ASCII string Hello step by step:

Convert to bytes: H=0x48, e=0x65, l=0x6C, l=0x6C, o=0x6F
Write as 40 bits: 01001000 01100101 01101100 01101100 01101111
Split into 5-bit groups: 01001 00001 10010 10110 11000 11011 00011 01111
Map each group to the RFC 4648 alphabet: J B S W Y 3 D P
Pad to a multiple of 8 characters: JBSWY3DP (40 bits = 8 chars exactly - no padding needed here)

For the string Hello World the output is JBSWY3DPEB3W64TMMQ======.

Frequently asked questions

Is Base32 encryption?

No. Base32 only changes how bytes are written as text; anyone can decode it. Do not use Base32 to hide passwords, TOTP seeds, or other secrets.

When should I decode Base32 as hex bytes?

Choose Hex bytes when the decoded data is binary rather than UTF-8 text. TOTP secrets are random byte sequences, so their text view can contain replacement characters; hexadecimal shows each byte without changing it.

What is the difference between RFC 4648, Base32hex, and Crockford?

RFC 4648 uses A–Z and 2–7 and is common for TOTP secrets. Base32hex uses 0–9 and A–V so encoded values preserve ordering useful to DNS. Crockford uses a human-oriented alphabet that omits I, L, O, and U and accepts common I/L/O aliases when decoding.

Why does Base32 sometimes end with equals signs?

Padding with = makes the encoded length a multiple of eight characters, as required by common RFC 4648 output. Some systems accept unpadded Base32 when the original byte length is known, so this tool lets you omit padding while encoding.