Base64 to Hex Converter — RFC 4648 Binary Encoding Technical Guide
Convert between Base64 and hexadecimal encodings client-side using RFC 4648 compliant algorithms with URL-safe variant support.
01. Binary Encoding: RFC 4648 Base64 & Hexadecimal
Base64 encoding (RFC 4648) converts arbitrary binary data into 64 printable ASCII characters using a 6-bit per character scheme. Every 3 bytes produce exactly 4 Base64 characters, resulting in 33% overhead. The alphabet uses A-Z, a-z, 0-9, +, and / with = as padding.
Hexadecimal (Base16) represents each byte as two characters from 0-9 and A-F, producing 100% overhead. Hex encoding is universally used in cryptographic digests (SHA-256, MD5), memory address representations, and protocol debugging.
RFC 4648 Section 5 defines a URL-safe Base64 variant replacing + with - and / with _ to eliminate characters requiring percent-encoding in HTTP URLs and JSON Web Tokens (JWT). This tool supports all variants: standard Base64, URL-safe Base64, and hexadecimal.
- Standard Base64: A-Z, a-z, 0-9, +, / with = padding — for MIME, PEM, X.509 certificates.
- URL-Safe Base64: - and _ substitutions — for JWT, OAuth tokens, URL query parameters.
- Hexadecimal (Base16): 2 hex chars per byte — standard for SHA digests and AES keys.
- UTF-8 BOM detection: flags invisible U+FEFF bytes that break downstream parsers.
- 33% vs 100% overhead: Base64 is more space-efficient than hex for binary data.
02. UTF-8 BOM Detection & Encoding Edge Cases
A Byte Order Mark (BOM) is a sequence of bytes (0xEF 0xBB 0xBF for UTF-8) prepended to some text files by Windows tools. When Base64-decoding a value producing a UTF-8 BOM, an invisible U+FEFF character breaks JSON parsers, XML validators, and HTTP header parsers.
Multibyte characters: Emoji and CJK characters encode to 3-4 bytes each in UTF-8 Base64. A single emoji in Base64 produces 4-8 characters. This is important when estimating encoded output sizes for API payload limits.
- UTF-8 BOM: auto-detected and flagged to avoid invisible parser breaks.
- Multibyte: emoji and CJK are 3-4 UTF-8 bytes each — 4-8 Base64 chars per emoji.
- Double-encoding: applying Base64 twice produces nested output requiring two decode passes.
Frequently Asked Questions (FAQ)
Difference between standard Base64 and URL-safe Base64?
Standard Base64 uses + and / which need percent-encoding in URLs. URL-safe Base64 (RFC 4648 §5) replaces them with - and _ for safe use in JWT and HTTP query strings.
Why does hex output have double the character count?
Hexadecimal encodes each 8-bit byte as exactly 2 characters (00-FF), so a 32-byte SHA-256 digest always produces 64 hex characters.
Is my confidential data uploaded to external servers when using Base64 & Hex Encoder / Decoder — Online UTF-8 Converter?
No. Core processing in Base64 & Hex Encoder / Decoder — Online UTF-8 Converter executes in volatile browser memory without server uploads. Inputs to local tools are not logged on remote servers; optional cloud-assisted features require user consent.
Can I use Base64 & Hex Encoder / Decoder — Online UTF-8 Converter offline without an active internet connection?
Offline use requires the page and its tool assets to finish caching first. Core transformations can then run locally; optional AI and contact delivery require internet.
Is Base64 & Hex Encoder / Decoder — Online UTF-8 Converter free to use with any rate limits or paywalls?
Core tools are free to use without an account. Device memory and tool-specific safety limits apply. Optional AI and online contact services have usage limits.