About

Base64 encoding represents binary data as ASCII text using a 64-character alphabet (A - Z, a - z, 0 - 9, +, /) plus = for padding. JavaScript source code is frequently distributed in Base64 form inside data URIs, obfuscated payloads, API responses, and build artifacts. Decoding it incorrectly - especially when multi-byte UTF-8 sequences are present - produces garbled output or silent data corruption. This tool applies the full RFC 4648 decode pipeline with proper TextDecoder reconstruction, so characters outside the ASCII plane (emoji, CJK, diacritics) survive intact.

The converter also accepts URL-safe Base64 (RFC 4648 §5), which replaces + with − and / with _. Padding may be absent in URL-safe variants; the tool re-pads automatically before decoding. Output is syntax-highlighted with a hand-rolled JavaScript lexer - no external dependencies. Note: this tool decodes Base64 to text. It assumes the encoded payload is valid UTF-8 text. Binary payloads (images, WASM) will produce unreadable output.

Formulas

Base64 encoding maps every 3 input bytes (24 bits) to 4 output characters (6 bits each). The output length is:

L_out = 4 ⋅ ⌈ L_in3 ⌉

Where L_in = input byte count, L_out = Base64 character count (with padding). The decoding reversal extracts the original bytes:

L_decoded = 34 ⋅ L_out − P

Where P = number of padding characters (0, 1, or 2). For URL-safe Base64, the alphabet substitution is: + → − and / → _. The decode pipeline in this tool: (1) strip whitespace, (2) detect and normalize URL-safe characters, (3) re-pad if necessary, (4) validate character set via regex, (5) call native atob, (6) reconstruct UTF-8 via TextDecoder.

Reference Data

Character Set	Alphabet	Padding	RFC	Common Use
Standard Base64	A - Z, a - z, 0 - 9, +, /	=	RFC 4648 §4	Email (MIME), PEM certificates
URL-safe Base64	A - Z, a - z, 0 - 9, −, _	Optional	RFC 4648 §5	URLs, JWT tokens, filenames
Base64 (MIME)	Same as standard	=	RFC 2045	Email attachments, line-wrapped
Base32	A - Z, 2 - 7	=	RFC 4648 §6	TOTP secrets, DNS
Base16 (Hex)	0 - 9, A - F	None	RFC 4648 §8	Hash digests, color codes
Input Byte Length	n bytes → 4 ⋅ ⌈ n / 3 ⌉1 Base64 characters (with padding)
Overhead	33.3% size increase vs raw binary
1 byte input	4 Base64 chars		2 data chars + 2 padding
2 byte input	4 Base64 chars		3 data chars + 1 padding
3 byte input	4 Base64 chars		4 data chars + 0 padding
Padding Rule	Pad with = until length is divisible by 4
Invalid Characters	Any char outside alphabet causes decode failure
Line Length (MIME)	Max 76 chars per line (RFC 2045)
Whitespace	Ignored by most decoders (stripped before processing)
Empty Input	Decodes to empty string (zero bytes)

Frequently Asked Questions

The native atob function decodes Base64 to a binary string where each character represents one byte. For multi-byte UTF-8 sequences (any codepoint above 127), a single character is split across 2 - 4 bytes. Reading them as individual Latin-1 characters produces mojibake. This tool converts the binary string to a Uint8Array and passes it through TextDecoder("utf-8") to correctly reassemble multi-byte sequences.

URL-safe Base64 replaces + with − and / with _ to avoid conflicts in URLs and filenames. The tool auto-detects URL-safe encoding by checking for the presence of − or _ characters, then substitutes them back to standard alphabet before calling atob. Missing padding is also restored automatically: if the length modulo 4 is 2, two = are appended; if 3, one = is appended.

This error occurs when the input contains characters outside the Base64 alphabet. Common culprits: curly quotes from word processors, BOM markers (U+FEFF), zero-width spaces, or accidental inclusion of surrounding JSON quotes. The tool pre-validates input with a strict regex and reports the exact position and character that caused the failure.

This converter targets text output (JavaScript source code). Binary payloads decoded as UTF-8 text will produce replacement characters (U+FFFD) or unreadable sequences. For binary data, you need a tool that outputs the raw byte stream as a downloadable file rather than displaying it as text.

The tool includes a hand-rolled JavaScript lexer that scans the decoded output character by character. It classifies tokens into categories: keywords (const, function, return), strings (single-quote, double-quote, backtick with template literal support), numbers (decimal, hex, binary, octal, exponential), comments (line and block), regex literals, operators, and punctuation. Each token is wrapped in a <span> with a CSS class for coloring. The lexer handles edge cases like regex vs division disambiguation and escaped characters within strings.

The tool processes input in the browser's main thread using native atob, which is highly optimized. Practical limits depend on available memory. Inputs up to approximately 5MB of Base64 text (decoding to ~3.75MB) work reliably in modern browsers. Syntax highlighting is disabled automatically above 100,000 characters of decoded output to prevent UI freezing.