Base32 Encoder / Decoder

Continue in the tool

More pages for this tool

decode totp secret key base32

TOTP secret key in Base32, alphabet and minimum length

An authenticator app's key never shows up as raw bytes: it always arrives in Base32, the A-Z plus 2-7 alphabet defined by RFC 4648 section 6. That choice is not arbitrary. RFC 6238 (TOTP) and RFC 4226 (HOTP, the basis for TOTP) define how that key turns into a 6-digit code every 30 seconds, but it is Base32 that decides how the key travels between server, QR code and keyboard.

From the alphabet to the RFC 4226 security floor

The Base32 alphabet used in TOTP is A-Z plus 2-7, 32 symbols, with no 0, 1, 8 or 9: they are excluded because 0 looks like O and 1 looks like I or L, and reserving only 2-7 for digits avoids that confusion when typing a key by hand. The padding character is =, used to round the output up to a multiple of 8 characters, but most 2FA apps accept the key without that padding, because the length of a 10- or 20-byte key is already implicit.
RFC 4226, section 4, defines the shared secret's length requirement: at least 128 bits (16 bytes), with a recommendation of 160 bits (20 bytes). The RFC's own classic example, the key "Hello!" followed by four extra bytes, decodes from JBSWY3DPEHPK3PXP to exactly 10 bytes, 80 bits: below the minimum, because it is a teaching example, not a real key. A real 2FA service generates 20 random bytes, which decodes to a 32-character Base32 key with no padding.
RFC 6238 defines how that decoded key turns into a code: the HOTP counter does not increment on each use, it is the Unix time divided by 30 and truncated, so the code changes every 30-second window regardless of how many times the user looks at the screen. The default algorithm is HMAC-SHA1 over that counter, truncated to 6 decimal digits. Swapping Base32 for any other encoding would break interoperability: every authenticator app expects to receive and hand back the key in this exact format, not in hex or Base64.

Two keys, two length verdicts

The RFC's teaching example, below the minimum

Input: JBSWY3DPEHPK3PXP
Expected output: 10 bytes, 80 bits, abaixo do piso de 128 bits do RFC 4226

Decodes to "Hello!" plus 4 bytes (48 65 6c 6c 6f 21 de ad be ef); it is the RFC's classic example, too short to protect a real account.

20-byte secret, the recommended size

Input: 20 bytes aleatórios
Expected output: AMFBCGA7EYWTIO2CJFIFOXTFNRZXVAMI

32 characters, no padding: 20 bytes times 8 bits divided by 5 bits per symbol closes out at exactly 32, with nothing left over, so no "=" is needed.

The same key with spaces, as an app shows it on screen

Input: AMFB CGA7 EYWT IO2C JFIF OXTF NRZX VAMI
Expected output: decodifica igual a AMFBCGA7EYWTIO2CJFIFOXTFNRZXVAMI, sem espaços

Spaces are just presentation: a correct Base32 decoder ignores that visual grouping and reads the same 32 data symbols.

Full tool FAQ

Which Base32 variant should I use?

If the other side says RFC 4648 without qualifying, it means the A-Z2-7 alphabet with padding. Use base32hex when the alphabetical order of the encoded text has to follow the numeric order of the data, which is the case for NSEC3 in DNSSEC. Use Crockford when the code will be read and typed by people and you want to catch errors on the spot with the check symbol. Use z-base-32 when the value will be spoken aloud. Picking the wrong one corrupts nothing, but the other side will not be able to decode it.

Why does Crockford turn O into 0 and I into 1?

What is the Crockford check symbol?

Is my 2FA secret Base32?

How long should a TOTP key be?

What does the non-canonical trailing bits warning mean?

What is the overhead of Base32?

Does Base32 protect my data?

Frequently asked questions

Why does the TOTP key use Base32 instead of Base64?

Because Base32 is case-insensitive and uses only 32 symbols with no ambiguous pairs like 0/O and 1/I/L, which matters when the key has to be typed by hand into an app, not just scanned from a QR code. Base64 is case-sensitive and includes + and /, symbols that make typing and reading aloud harder.

Is the example key JBSWY3DPEHPK3PXP safe to actually use?

No. It decodes to only 10 bytes, 80 bits, below the 128 bits RFC 4226 requires as the minimum for the shared secret. It is the RFC's own teaching example, built to illustrate the structure, not a key any real service should generate; serious services generate at least 160 bits (20 bytes).

Why does the TOTP code change every 30 seconds and not on every use?

Because RFC 6238 defines the counter as the current Unix time divided by 30 and floored, not an incrementing counter like plain HOTP (RFC 4226). That means the server and the app arrive at the same code independently, with no need to sync calls between them, as long as both clocks stay aligned.

Next steps

Continue in the tool

Open full tool

decode totp secret key base32

TOTP secret key in Base32, alphabet and minimum length

From the alphabet to the RFC 4226 security floor

The Base32 alphabet used in TOTP is A-Z plus 2-7, 32 symbols, with no 0, 1, 8 or 9: they are excluded because 0 looks like O and 1 looks like I or L, and reserving only 2-7 for digits avoids that confusion when typing a key by hand. The padding character is =, used to round the output up to a multiple of 8 characters, but most 2FA apps accept the key without that padding, because the length of a 10- or 20-byte key is already implicit.

RFC 4226, section 4, defines the shared secret's length requirement: at least 128 bits (16 bytes), with a recommendation of 160 bits (20 bytes). The RFC's own classic example, the key "Hello!" followed by four extra bytes, decodes from JBSWY3DPEHPK3PXP to exactly 10 bytes, 80 bits: below the minimum, because it is a teaching example, not a real key. A real 2FA service generates 20 random bytes, which decodes to a 32-character Base32 key with no padding.

RFC 6238 defines how that decoded key turns into a code: the HOTP counter does not increment on each use, it is the Unix time divided by 30 and truncated, so the code changes every 30-second window regardless of how many times the user looks at the screen. The default algorithm is HMAC-SHA1 over that counter, truncated to 6 decimal digits. Swapping Base32 for any other encoding would break interoperability: every authenticator app expects to receive and hand back the key in this exact format, not in hex or Base64.

Two keys, two length verdicts

The RFC's teaching example, below the minimum

Input: JBSWY3DPEHPK3PXP
Expected output: 10 bytes, 80 bits, abaixo do piso de 128 bits do RFC 4226

Decodes to "Hello!" plus 4 bytes (48 65 6c 6c 6f 21 de ad be ef); it is the RFC's classic example, too short to protect a real account.

20-byte secret, the recommended size

Input: 20 bytes aleatórios
Expected output: AMFBCGA7EYWTIO2CJFIFOXTFNRZXVAMI

32 characters, no padding: 20 bytes times 8 bits divided by 5 bits per symbol closes out at exactly 32, with nothing left over, so no "=" is needed.

The same key with spaces, as an app shows it on screen

Input: AMFB CGA7 EYWT IO2C JFIF OXTF NRZX VAMI
Expected output: decodifica igual a AMFBCGA7EYWTIO2CJFIFOXTFNRZXVAMI, sem espaços

Spaces are just presentation: a correct Base32 decoder ignores that visual grouping and reads the same 32 data symbols.

Full tool FAQ

Which Base32 variant should I use?

Why does Crockford turn O into 0 and I into 1?

What is the Crockford check symbol?

Is my 2FA secret Base32?

How long should a TOTP key be?

What does the non-canonical trailing bits warning mean?

What is the overhead of Base32?

Does Base32 protect my data?

Frequently asked questions