User Rating 0.0 ★★★★★

Total Usage 0 times

Category JSON Tools

Base64 Input Whitespace and line breaks are stripped automatically.

URL-safe Base64 (JWT)

Indent

JSON Output

Decoded JSON will appear here...

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

Base64 encoding transforms binary or text data into a 64-character ASCII subset for safe transport across systems that corrupt raw bytes - email (MIME), URLs, JSON Web Tokens, and API payloads. The alphabet uses A - Z, a - z, 0 - 9, +, /, with = as padding. Each output character encodes 6 bits, so 3 input bytes become 4 Base64 characters - a fixed overhead of roughly 33%. Decoding a Base64 string that is supposed to contain JSON is a two-stage operation: first reverse the Base64 encoding to recover the raw UTF-8 byte stream, then parse those bytes as JSON according to RFC 8259. Failure at either stage means corrupted data or a broken integration.

This tool performs both stages with explicit error reporting. If the Base64 is malformed (wrong length, illegal characters), the decoder rejects it before JSON parsing begins. If decoding succeeds but the result is not valid JSON, the parser reports the exact character position of the syntax error. The tool assumes UTF-8 encoding, which covers all valid JSON per the specification. Note: this tool does not handle URL-safe Base64 (RFC 4648 §5) automatically - if your input uses - and _ instead of + and /, enable the URL-safe toggle before decoding.

Formulas

Base64 encoding maps every group of 3 input bytes (24 bits) onto 4 output characters (6 bits each). The encoded length is computed as:

L_encoded = 4 ⋅ ceil(L_input3)

where L_input = byte length of the original data and L_encoded = character count of the Base64 string (including padding). Decoding reverses this: each Base64 character is mapped to its 6-bit index via the alphabet lookup table, the bits are concatenated, and then split back into 8-bit bytes.

L_decoded = 34 ⋅ L_encoded − P

where P = number of padding characters (0, 1, or 2). For URL-safe Base64, the conversion step replaces - → + and _ → / before decoding, then re-applies padding if absent:

P_needed = (4 − L_encoded mod 4) mod 4

After decoding to a UTF-8 string, the result is fed to a strict JSON parser. A valid JSON document must begin with { or [ (or a scalar value per RFC 8259). The parser validates syntax including matched braces, correct comma placement, properly escaped strings, and number formats.

Reference Data

Property	Standard Base64 (RFC 4648 §4)	URL-Safe Base64 (RFC 4648 §5)
Alphabet	A - Z, a - z, 0 - 9, +, /	A - Z, a - z, 0 - 9, -, _
Padding character	=	= (often omitted)
Encoding ratio	3 bytes → 4 chars	3 bytes → 4 chars
Size overhead	~33%	~33%
Safe for URLs	FALSE	TRUE
Safe for filenames	FALSE	TRUE
Line breaks (MIME)	Every 76 chars	None
Use in JSON (RFC 8259)	String value only	String value only
Use in JWT (RFC 7519)	Not used	Header, Payload, Signature
Use in Data URIs	After base64, prefix	Not standard
Max input for atob()	Browser-dependent (~512MB)	Requires pre-conversion
Valid JSON types	object, array, string, number, TRUE, FALSE, NULL
JSON max nesting (practical)	512 levels (browser limit)
JSON encoding	UTF-8 (mandatory per RFC 8259)
Common error: trailing whitespace	Causes InvalidCharacterError
Common error: BOM prefix	UTF-8 BOM (0xEF 0xBB 0xBF) breaks JSON.parse
Common error: single quotes	Not valid JSON - only double quotes
Bit group size	6 bits per character	6 bits per character
Padding logic	0 remainder → 0 pads, 1 remainder → 2 pads, 2 remainder → 1 pad	Same or omitted

Frequently Asked Questions

The Base64 string decoded correctly into a UTF-8 string, but that string is not valid JSON. Common causes: the original data used single quotes instead of double quotes (JSON requires double quotes per RFC 8259), contains a UTF-8 BOM prefix (0xEF 0xBB 0xBF), includes trailing commas after the last element in an array or object, or contains JavaScript-style comments. The error message includes the character position - inspect that location in the decoded output.

A JWT consists of three URL-safe Base64 segments separated by dots: header, payload, and signature. Copy only the header or payload segment (not the full token) and enable the URL-safe Base64 toggle. The tool will convert - to + and _ to /, add padding, then decode. The header and payload are valid JSON objects. The signature segment is binary data and will not parse as JSON.

The browser's atob() function and JSON.parse() both operate in memory. Practical limits depend on available RAM, but most modern browsers handle strings up to approximately 512MB. For inputs exceeding 10MB of Base64, expect a brief delay. The tool processes everything synchronously since the decode-parse pipeline is linear and typically completes in under 100ms for typical payloads.

Yes. The tool uses TextDecoder with UTF-8 encoding to properly reconstruct multi-byte sequences. The native atob() returns a binary string (Latin-1), which is then converted byte-by-byte into a Uint8Array and fed to TextDecoder. This correctly handles 1-byte to 4-byte UTF-8 sequences including emoji, CJK, Cyrillic, and Arabic characters.

MIME-encoded Base64 (RFC 2045) inserts a line break every 76 characters. The tool automatically strips all whitespace characters (spaces, tabs, carriage returns, newlines) before decoding. This means you can paste Base64 from email headers, PEM certificates, or multiline API responses without manual cleanup.

Yes - and this is common in APIs that double-encode data. The tool will decode the outer Base64 layer and parse the JSON. If a JSON string value itself contains Base64, you would need to copy that value and decode it separately. The tool does not automatically recurse into nested encodings because not all string values are Base64, and automatic detection would produce false positives.