Base64 Decode & Encode
Base64 Decode & Encode converts text and binary data between raw bytes and the RFC 4648 Base64 and base64url alphabets, handles line-wrapped MIME input, and automatically detects JSON Web Tokens to show their header and claims. Everything runs locally; tokens are decoded, never transmitted.
(empty result)
How does Base64 Decode & Encode work?
Base64 is the foundational binary-to-text serialization algorithm of computer networking, specified in RFC 4648. Its purpose is not encryption, but safe transport: many legacy protocols were engineered for 7-bit ASCII, so raw 8-bit binary payloads — images, cryptographic keys, compiled modules — are projected into a 64-character subset of printable ASCII characters.
The encoder processes the input byte stream in sequential blocks of 3 bytes (24 bits). Since each Base64 character represents 6 bits of information, each 24-bit block is cleanly partitioned into exactly four 6-bit indices (0–63) that map to uppercase A–Z, lowercase a–z, digits 0–9, plus + and /. Because 3 input bytes produce 4 output characters, encoding inherently expands the payload by roughly one-third. Inputs whose length is not a multiple of 3 are zero-bit-padded and completed with = characters so every block is 4 characters wide.
Standard Base64 uses + and / for indices 62 and 63, but both characters have reserved meanings in URIs and form data, so RFC 4648 Section 5 defines the URL-safe alphabet (base64url), replacing them with - and _ and usually dropping trailing padding. JSON Web Tokens (RFC 7519), WebAuthn credentials, and OAuth PKCE verifiers mandate this variant.
This tool automatically evaluates the token geometry of any pasted string: when three period-delimited base64url segments with valid JSON structures are detected, it renders an inspection interface with decoded header and claim cards alongside human-readable dates — all computed locally, with nothing ever sent over the network.
Example input
SGVsbG8gV29ybGQ=
Example output
Hello World
What is inside the first segment of a JWT?
A JSON Web Token's header is ordinary Base64url. Decoding it needs no key and proves nothing about the token — it only says which algorithm the issuer claims to have used.
Base64url
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Decoded text
{"alg":"HS256","typ":"JWT"}Base64 is an encoding, not encryption: anyone holding the string can read this. Never put a secret in a token segment and assume the encoding hides it.
What options and edge cases does Base64 Decode & Encode support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Standard alphabet | RFC 4648 | A–Z a–z 0–9 + / | The classic 64-character lookup table with = padding, used in MIME email, XML, and inline images. |
| URL-safe alphabet | RFC 4648 §5 | A–Z a–z 0–9 - _ | Replaces + and / with - and _ so tokens survive URLs and query strings; padding is usually omitted. |
| JWT inspection | Feature | auto | Three period-separated base64url segments are auto-detected and rendered as decoded header and claim cards. |
| Binary download | Feature | auto | Decoded bytes are packaged into a typed Blob with MIME type and extension guessed from magic bytes. |
Frequently asked questions
How does Base64 encoding represent binary data as ASCII text?
Base64 operates on 24-bit chunks of binary data, which corresponds to 3 standard 8-bit bytes. These 24 bits are partitioned into four 6-bit groups (since 2^6 = 64). Each 6-bit integer (ranging from 0 to 63) maps directly to a predefined index table consisting of uppercase A-Z (0-25), lowercase a-z (26-51), digits 0-9 (52-61), plus '+' (62), and '/' (63). If the input byte length is not divisible by 3, the final block is padded with zero bits, and '=' padding characters are appended to satisfy the 4-character alignment constraint.
What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 according to RFC 4648 uses '+' (index 62) and '/' (index 63), and pad characters '='. In URLs, filenames, and HTTP query strings, '+' denotes a space, and '/' acts as a path delimiter, which causes parsing ambiguities or requires percentage escaping. RFC 4648 Section 5 defines URL-safe Base64 (base64url), replacing '+' with '-' (hyphen) and '/' with '_' (underscore), while often omitting trailing '=' padding characters altogether. JWTs (RFC 7519) strictly mandate the URL-safe base64url alphabet without padding.
Can I decode Base64 data containing sensitive passwords or tokens here safely?
Yes, completely. ToolsByUs executes 100% locally within your browser's V8 JavaScript engine. Zero network requests, zero API calls, zero telemetry, and zero server logging occur when you paste or process payloads. You can disconnect your internet connection or inspect your browser's DevTools Network panel to independently verify zero data transmission.
How does the tool automatically detect and inspect JSON Web Tokens (JWT)?
A standard JWT consists of three base64url-encoded parts separated by period '.' delimiters: header, payload, and signature. When you paste an input containing two periods separating base64url strings, the parser decodes the first two segments. If both segments parse into valid JSON containing typical JWT properties such as 'alg', 'typ', or registered claims ('exp', 'sub', 'iat'), the tool immediately displays decoded JSON cards alongside human-readable expiration dates.
How does the binary file download guess MIME types and file extensions?
When decoding Base64 back into raw Uint8Array bytes, the decoder reads the file's 'magic bytes' (initial header signature). For instance, PNG files begin with 0x89 0x50 0x4E 0x47 ('\x89PNG'), JPEG begins with 0xFF 0xD8 0xFF, PDF begins with 0x25 0x50 0x44 0x46 ('%PDF'), and ZIP begins with 0x50 0x4B 0x03 0x04 ('PK'). Based on these magic signatures, the browser synthesizes a typed Blob for direct local download.
Why does my Base64 string fail to decode?
Usually one of three things: it was copied out of an email or a terminal and carries line breaks, it is URL-safe Base64 using - and _ being read as the standard alphabet, or the trailing = padding was trimmed somewhere. This tool handles all three — whitespace is stripped, both alphabets are accepted and missing padding is restored. What no tool can recover from is a string that lost characters in transit.