Base32가 존재하는 이유는 하나다. 코드를 소리 내어 읽거나, 전화로 불러주거나, 손으로 옮겨 적어야 할 때 Base64의 64개 문자보다 32개 문자로 이루어진 알파벳이 훨씬 오류가 적게 발생한다.
QR코드를 스캔하지 못할 때 등장하는 Base32
Google Authenticator 같은 앱이 QR코드를 스캔하지 못하면 손으로 입력할 수 있는 "설정 키"를 대신 보여준다 — 이 키는 Base64가 아니라 Base32로 인코딩되어 있다. 한국에서는 QR코드 인식률이 매우 높아 수동 입력 화면을 볼 일이 드물지만, 카메라 권한이 없거나 PC에서 앱을 설정할 때는 반드시 이 Base32 키가 등장한다.
구술에도 안전하도록 설계된 알파벳
Base32는 0, 1, 8, 9와 문자 O, I, L을 완전히 제외한다 — 전화로 불러주거나 저해상도 화면에서 가장 헷갈리기 쉬운 문자들이다. 로마자 표기에 익숙하지 않은 상황에서 숫자 0과 알파벳 O를 음성만으로 구분하는 것은 어렵다. Base32는 이 모호함을 알파벳 설계 단계에서 아예 없애버린다.
실제로 어디에 쓰이는가
- Tor 네트워크의 .onion 주소 — 56자리 서브도메인은 Ed25519 공개키를 Base32로 인코딩한 것이다.
- 대소문자를 구분하지 않는 DNS 레이블과 서브도메인.
- 영수증에 인쇄된 추천인 코드나 쿠폰 코드 — 고객이 웹사이트에 직접 다시 입력해야 하는 경우.
가독성의 대가 — 더 길어지는 문자열
알파벳이 작을수록 바이트당 필요한 문자 수는 늘어난다 — 결과물은 Base64보다 약 60% 더 길다. 20바이트짜리 비밀 키라면 이 차이는 미미하지만, 수 메가바이트짜리 파일에 Base32를 쓰는 것은 현실적이지 않다.
Base32와 Base32hex는 서로 호환되지 않는다
RFC 4648은 Base32hex도 정의하는데, A–Z2–7 대신 0–9A–V 알파벳을 사용하며 인코딩된 문자열의 정렬 순서를 원본 바이트의 순서와 동일하게 유지한다 — 일부 데이터베이스에 중요한 특성이다. 한쪽 방식으로 인코딩한 문자열은 다른 방식으로 올바르게 디코딩되지 않으므로, 디코딩 전에 실제로 어떤 방식이 쓰였는지 확인해야 한다.