Base64 Decoder

Base64 is a binary-to-text encoding scheme that represents arbitrary binary data using a set of 64 printable ASCII characters: the 26 uppercase letters A–Z, the 26 lowercase letters a–z, the digits 0–9, and the two symbols + and / (with = used as a padding character). The name "Base64" comes directly from the 64-character alphabet the scheme uses.

The fundamental problem Base64 solves is transport safety. Many communication channels — email protocols like SMTP, HTTP headers, URLs, and XML/JSON documents — were originally designed to carry only 7-bit ASCII text. Binary data such as images, cryptographic keys, or compressed files cannot pass through these channels without corruption. Base64 converts any binary payload into a stream of safe ASCII characters that survives transport unchanged, regardless of the underlying protocol or system.

You will encounter Base64 in a remarkable range of everyday technology. Email attachments are Base64-encoded inside MIME messages. Images embedded in HTML or CSS use Base64 data URIs (data:image/png;base64,...). JSON Web Tokens (JWTs) store their header and payload as Base64url-encoded strings. API credentials are frequently sent as Base64-encoded username:password pairs in HTTP Basic Authentication headers. TLS/SSL certificates stored in PEM format are Base64-encoded DER binary. Even many database BLOBs are stored as Base64 for compatibility.

Our Base64 decoder calculator reverses the encoding process: you paste any Base64 string and instantly receive the original plain text. The tool supports both standard Base64 (using + and /) and the URL-safe variant (using - and _), which is essential for decoding JWTs, OAuth tokens, and anything embedded in a URL where + and / carry special meaning. The input and output length counters update in real time, so you can immediately see the compression ratio between the encoded and decoded forms.

Base64 encoding works by grouping every three bytes of input (24 bits) into four 6-bit chunks, then mapping each 6-bit value to one of the 64 printable characters in the Base64 alphabet. Decoding simply reverses this: every four Base64 characters are looked up in the alphabet to recover six bits each, yielding 24 bits (three bytes) of original data. This 4:3 character-to-byte ratio means a Base64-encoded string is always approximately 33 percent longer than the original binary data.

When the original data's byte count is not a multiple of three, one or two = padding characters are appended to the encoded string to keep its length a multiple of four. One = means the last group encoded only one byte; two == means it encoded two bytes. The padding is stripped and the correct number of output bytes is inferred during decoding.

This calculator uses the browser's built-in atob() function, which implements the standard Base64 decoding algorithm directly. To correctly handle text that contains multibyte characters (such as accented letters or emoji encoded in UTF-8), the tool additionally wraps the result in decodeURIComponent(escape(...)). This two-step process converts the raw byte string returned by atob() into a proper JavaScript Unicode string, so that encoded UTF-8 text is displayed correctly rather than as garbled bytes.

When the URL-safe checkbox is checked, a preprocessing step runs before decoding: every - in the input is replaced with +, and every _ is replaced with /, restoring the standard Base64 alphabet. The string is then padded with = characters until its length is a multiple of four, because URL-safe Base64 (used in JWTs and OAuth) typically omits padding. After these substitutions, the standard decoding pipeline runs as normal.

The original Base64 specification (RFC 4648 §4) uses a 64-character alphabet that includes the + and / symbols. These two characters have reserved meanings in URLs — + represents a space in query strings, and / is a path separator — so embedding standard Base64 in a URL requires additional percent-encoding, producing strings like SGVsbG8%2C%20V29ybGQ%3D that are long, unreadable, and error-prone.

The URL-safe (or "Base64url") variant defined in RFC 4648 §5 replaces + with - and / with _, producing strings that can be embedded in URLs and filenames without any percent-encoding. Padding = characters are also commonly omitted in URL-safe contexts because they can be ambiguous in query strings.

The most widespread use of URL-safe Base64 today is in JSON Web Tokens (JWTs). A JWT consists of three URL-safe Base64url-encoded sections separated by dots: header.payload.signature. To inspect a JWT's header or payload — for example, to check its expiry time or the user's claims — you paste one section (without the dots) into this decoder and check the URL-safe checkbox. The tool handles both the character substitution and the missing padding automatically.

Other common URL-safe Base64 contexts include OAuth 2.0 tokens, PKCE code challenges, API key generation, and base64url-encoded file names in cloud storage systems. Whenever you see a Base64-looking string containing - or _ instead of + or /, you are looking at URL-safe Base64 and should enable that checkbox before decoding.

A Base64 decoder is an indispensable utility for developers, security professionals, and anyone who works with APIs, tokens, or encoded data. Here are the most common real-world scenarios where this tool saves time.

Inspecting JWT Tokens

JWTs are the most common authentication token format in modern web APIs. Each JWT contains a Base64url-encoded header and payload. Decoding the payload lets you read the user's identity claims, expiry timestamp (exp), issuing authority (iss), and any custom attributes — without needing a private key. Paste the section between the first and second dots into this decoder with URL-safe mode enabled to instantly inspect any JWT payload.

Debugging API Responses

REST and GraphQL APIs occasionally return fields as Base64-encoded strings — cursor-based pagination cursors, opaque IDs, or binary attachments. Decoding these values reveals the underlying structure (often JSON or a colon-separated composite key), which is invaluable when troubleshooting unexpected API behavior.

Reading Email Attachments and MIME Parts

Email messages that contain attachments encode them in Base64 within MIME multipart bodies. If you are building or debugging an email parser, or if you receive raw SMTP traffic in a log file, a Base64 decoder lets you recover the original attachment content from the encoded block.

Working with Data URIs

HTML and CSS support inline resources via data URIs: data:image/png;base64,iVBORw0KGgo.... Decoding the Base64 portion of a data URI lets you extract the embedded image or font file, inspect its contents, or convert it back to a standalone file.

Security Analysis and CTF Challenges

Capture-the-flag competitions frequently hide flags inside Base64-encoded strings, sometimes with multiple layers of encoding. Security analysts also use Base64 decoders when inspecting obfuscated malware payloads, encoded PowerShell commands (-EncodedCommand), or phishing kit source code where strings are Base64-encoded to evade signature detection.

Verifying Cryptographic Data

Public keys, certificate signing requests (CSRs), and digital signatures are often transmitted as PEM-format Base64. Decoding the body of a PEM block (the lines between the -----BEGIN... headers) produces the raw DER binary, which can then be parsed by cryptographic tools. This calculator handles the text decoding step quickly so you can focus on the cryptographic analysis.

This decoder displays two real-time counters: Input Length (the number of characters in the Base64 string you entered) and Output Length (the number of characters in the decoded text). Understanding the relationship between these numbers helps you verify that a decode was successful and understand why Base64 adds overhead to data size.

Every 4 characters of Base64 encode exactly 3 bytes of original data. This gives a constant expansion factor of 4/3 ≈ 1.333 — meaning a Base64 string is always about 33 percent larger than the binary data it encodes. Equivalently, the decoded output should always be approximately 75 percent of the input length (ignoring padding characters).

For plain ASCII text, the byte count equals the character count, so the output character counter matches the decoded byte count exactly. The formula is: Output bytes = ⌊(Input length × 3) / 4⌋ when the input is correctly padded. If the input length is not a multiple of 4 and you are not using URL-safe mode (which adds padding automatically), decoding will fail with an "Invalid Base64 input" error — a reliable diagnostic that tells you the string is truncated or corrupted.

For multibyte UTF-8 text such as accented European characters, Arabic script, or CJK characters, the output character count will be less than the byte count, because each character may occupy 2, 3, or 4 bytes in UTF-8. The output length counter shows the number of JavaScript string characters (Unicode code points in the BMP), not raw bytes. Keep this distinction in mind when decoding binary data vs. human-readable text.

A quick sanity check: if your input is 1000 characters long (without padding), the decoded output should be approximately 750 characters for plain ASCII text. If the output is dramatically shorter or the tool shows an error, the input is likely not valid Base64 — perhaps it is URL-encoded, hex-encoded, or has been corrupted during copy-paste.