Base64 Encoder & Decoder

What is Base64?

Base64 is a binary-to-text encoding that represents arbitrary bytes using a 64-character alphabet. The alphabet is fixed: A–Z, a–z, 0–9, +, and /, with = used for padding. Every three bytes of input become four characters of output. That's the entire specification — there is no key, no password, and no way to "decrypt" it because nothing is encrypted in the first place.

The reason Base64 exists is simple: many systems — email (SMTP), HTTP headers, URLs, JSON strings, XML text nodes — were designed to carry text, not raw bytes. If you need to move a PNG image, an X.509 certificate, or a salt value through one of those channels, you can't just shove the raw bytes in. Base64 gives you a text-safe representation that survives any transport that can carry 7-bit ASCII.

How Base64 encoding works

The algorithm is short enough to describe in a paragraph. Take three bytes (24 bits). Split them into four 6-bit groups. Map each 6-bit value (0–63) to a character from the Base64 alphabet. That's it. If the input length isn't a multiple of three, the final group is padded with zero bits and one or two = characters are appended so the output length is always a multiple of four.

Concretely, the string Hello encodes like this:

H  e  l  l  o          (5 bytes)
48 65 6C 6C 6F          (hex)
→ split into 6-bit groups, pad to multiple of 3 bytes
→ SGVsbG8=

The = at the end is padding: "Hello" is 5 bytes, so the last group only supplies 2 bytes and gets one padding character.

Base64 encoder example

Encoding text to Base64 is straightforward. Input:

Hello World

Output (standard Base64):

SGVsbG8gV29ybGQ=

The same input encoded as Base64URL (with padding) becomes:

SGVsbG8gV29ybGQ=

…and without padding:

SGVsbG8gV29ybGQ

Only payloads that contain the + or / characters differ between the two alphabets — everything else is identical.

Base64 decoder example

Decoding reverses the process: strip whitespace, restore padding if it was omitted, map each character back to its 6-bit value, and reassemble the original bytes. If the original bytes were UTF-8 text, you get back the string:

SGVsbG8gV29ybGQ=   →  Hello World

This tool uses the browser's native TextDecoder, so multi-byte UTF-8 characters — Hindi, Arabic, Chinese, Japanese, emojis — are decoded correctly. If the bytes are not valid UTF-8 (because they're a PNG, a PDF, or a random binary blob), the tool says so explicitly instead of showing mojibake.

Base64 vs Base64URL

Standard Base64 uses + and /, both of which are special in URLs. A + in a query string is decoded as a space; a / is a path separator. So RFC 4648 defines a URL-safe variant called Base64URL that swaps + for - and / for _. Padding (=) is also often dropped, since = is technically legal in URLs but ugly and occasionally ambiguous.

Base64URL appears everywhere in modern web infrastructure:

• JWT (JSON Web Tokens) — every segment is Base64URL-encoded
• OAuth 2.0 PKCE code challenges
• Web Push encryption payloads
• Signed URLs and CDN tokens
• Short, URL-safe identifiers in APIs

Base64URL is not a form of encryption. It encodes the same bytes as standard Base64 — only the character set changes.

Base64 vs URL encoding

These are often confused but do completely different things. URL encoding (also called percent-encoding) escapes characters that would be unsafe inside a URL, replacing them with a %XX hex sequence. Base64 re-encodes the entire payload — every byte — into a longer but always-safe character set. You'd use URL encoding to include a search term in a query string; you'd use Base64 to embed a PNG inside a JSON API payload.

Base64 is not encryption

This is the single most important thing to understand about Base64. The algorithm is public, deterministic, and requires no key. Anyone with the encoded string can decode it in one line of JavaScript:

atob("SGVsbG8gV29ybGQ=")   // → "Hello World"

Never use Base64 to protect a secret. It's useful for transport, not for confidentiality. If you need to protect data, use real encryption — AES-GCM, ChaCha20-Poly1305, libsodium — with a proper key-management strategy. If a system hands you a value that looks "encoded" and says "this is obfuscated", assume it's Base64 until proven otherwise and treat the underlying value as plaintext.

Encode files to Base64

Files are just bytes, so encoding them to Base64 works exactly the same way as encoding text. The File tab in this tool reads your file locally (via File.arrayBuffer()) and produces the Base64 string directly. Common cases:

• Images — inline small icons in CSS or HTML to remove extra HTTP requests.
• PDFs — embed a document inside a JSON payload to a print API.
• Certificates — PEM files are just Base64 with line wrapping and -----BEGIN----- headers.
• ZIPs / archives — attach a bundle inside a single API call.
• JSON / TXT — hold small fixtures or config snippets inline.

Base64 is about 33% larger than the raw bytes (4 output characters for every 3 input bytes), so a 1 MB file becomes roughly 1.37 MB of Base64. That's the trade-off for keeping the data text-safe.

Decode Base64 to files

The reverse direction is just as useful: given a Base64 string, rebuild the original bytes and hand them to the user as a file download. Enter the Base64, supply a MIME type and a filename, and click Download File. If the payload is an image type, a preview is rendered locally — no server involved. This tool never executes decoded content and never auto-opens files; downloads are always user-initiated.

A common workflow is to decode an attachment from an email API: the JSON response contains a field like {"content": "JVBERi0xLjQ…", "contentType": "application/pdf"}. Paste the base64, set the MIME to application/pdf, and download the original PDF.

Base64 Data URLs

A Data URL is a compact way to inline a resource directly into a document. The format is:

data:[<mime>][;charset=…][;base64],<payload>

For example:

data:text/plain;base64,SGVsbG8gV29ybGQ=

Data URLs are common in <img src="…">, in CSS background-image, and inside JSON responses from image-generation APIs. This tool auto-detects a Data URL prefix when you paste one, breaks the string into its three parts (MIME, encoding, payload), and shows you the breakdown. For image Data URLs, a preview is rendered in the browser without any network activity.

Two caveats when using Data URLs in production: they inflate the payload by ~33%, and they cannot be cached independently of the enclosing document. They're best for small assets — favicons, tiny SVGs, thumbnails.

Unicode and UTF-8

Naive Base64 implementations call btoa(text) and fail on anything outside the Latin-1 range. That's because btoa operates on JavaScript's internal UTF-16 code units, not on UTF-8 bytes. The correct approach is to convert the string to UTF-8 bytes first (TextEncoder), Base64-encode those bytes, and on decode reverse the process with TextDecoder. This tool does exactly that.

The practical consequence is that the same emoji, for example 👋, is one code point (U+1F44B), four UTF-8 bytes, and about eight Base64 characters. If you're calculating sizes, remember: JavaScript's string.length counts UTF-16 code units, not bytes. For an accurate "byte size" you must encode to UTF-8 first.

Base64 and JWT

A JSON Web Token has three parts, separated by dots:

header.payload.signature

The header and payload are JSON objects encoded with Base64URL (no padding). The signature is either a raw binary value (encoded the same way) or a JWS signature. Decoding a JWT is often the first step in debugging authentication — but this tool is not a JWT validator. It only handles the encoding layer. If you need to see the header and payload as readable JSON, use the dedicated JWT Debugger. It handles the three-part structure, applies the right decoding, and clearly marks that signature verification is not performed.

Base64 in APIs and JSON

REST and GraphQL APIs use Base64 for several recurring patterns: binary payloads inside JSON bodies (attachments, thumbnails), opaque pagination cursors, signed values, and encoded filter expressions. Because Base64 is text-safe and deterministic, it survives JSON string escaping without any surprises — the characters +, /, and = have no special meaning inside a JSON string.

If your API uses Base64URL for cursor values, you'll see the - and _ characters instead. Both are also safe inside JSON strings. The difference matters only when the value is placed directly into a URL path or query parameter.

Once you've decoded a JSON payload, the Universal Data Transformer can convert it to CSV, YAML, XML, SQL, or Markdown. If you have two decoded payloads and want to see what changed, the JSON Diff tool shows you exactly which fields were added, removed, or modified.

Padding explained

Because Base64 works in 3-byte groups, the input length mod 3 determines how many padding characters are needed:

• 0 bytes left over → no padding
• 1 byte left over → 2 padding characters (==)
• 2 bytes left over → 1 padding character (=)

Padding is only meaningful for interoperability. A decoder that ignores padding can reconstruct the original bytes without it, which is why Base64URL almost always omits padding. But some strict parsers (and many legacy systems) require padding, so when in doubt, keep it. This tool provides a "Keep padding" toggle for Base64URL.

Common Base64 errors

• "Invalid character" — a non-alphabet character slipped in (often whitespace, an emoji, or a stray unicode character from copy-paste). The tool reports the exact position.
• "Invalid length" — the string length mod 4 is 1, which is mathematically impossible. Usually means characters were dropped.
• "Unexpected padding" — = appears in the middle of the string, or there are more than two of them at the end.
• "Broken Data URL" — the data: prefix is present but the comma separating metadata from payload is missing.
• Mojibake after decode — the bytes were not valid UTF-8. Your data is binary; the tool says so explicitly instead of showing garbage characters.

Privacy and performance

Everything on this page runs locally. Your text, JSON, files, JWT payloads, images, and Base64 strings are never uploaded, never logged, and never sent to any external service. There are no analytics on the content you enter, and there is no server endpoint involved in the encoding or decoding — the browser's native atob / btoa / TextEncoder / TextDecoder do all the work.

For performance, this tool processes bytes in chunks rather than converting a whole file to a JavaScript string at once. Large files (tens of megabytes) work, but they will be slower to encode because of the ~33% expansion and browser memory limits. If a file is too large to handle comfortably, you'll see a clear size warning rather than a frozen tab.

Related developer tools

• JWT Debugger — decode the header, payload, and signature of any JWT.
• Universal Data Transformer — convert decoded JSON or delimited text to CSV, YAML, XML, SQL, or Markdown.
• JSON Diff — compare two decoded JSON payloads field-by-field.
• Unix Timestamp Converter — turn epoch values into readable dates.
• Regex Tester & Debugger — extract values from decoded text with regular expressions.
• JSON vs XML comparison guide — background on choosing a wire format.

Frequently asked questions

Is this Base64 tool free?

Yes. No signup, no limits, no rate limits. All processing is client-side.

Is my data uploaded anywhere?

No. Everything happens in your browser. Your text, files, and Base64 strings never leave the page.

Does Base64 encrypt my data?

No. Base64 is a reversible encoding, not encryption. Anyone with the encoded value can decode it. Use real cryptography (AES-GCM, ChaCha20-Poly1305) if you need confidentiality.

How much does Base64 inflate my data?

About 33% — every 3 bytes become 4 characters. A 1 MB file encodes to roughly 1.37 MB of Base64 text.

What is Base64URL and why does it exist?

Base64URL uses - and _ instead of + and /, because those two characters have special meaning in URLs. It's used by JWT, OAuth 2.0, Web Push, and signed URLs.

Why does my decoded text show weird symbols?

The bytes you decoded are not valid UTF-8 — probably a binary file (image, PDF, ZIP). This tool detects that case and shows "binary data" instead of garbage characters.

Does this tool support Unicode?

Yes. Text is encoded to UTF-8 bytes via TextEncoder before Base64 encoding, and reversed on decode. Hindi, Arabic, Chinese, Japanese, emojis, and mixed text all round-trip correctly.

Can I decode a JWT with this tool?

You can decode each segment individually, but the result is JSON — for a proper JWT workflow (auto-splitting the three parts, showing headers and payload separately) use the JWT Debugger.

Can I use this to encode a file I want to email?

Yes, but remember that Base64 output is ~33% larger than the file. For email specifically, use MIME encoding via your mail client — it does the same thing with the same overhead.

Does it handle very large files?

Up to the practical memory limits of your browser. Files in the tens-of-megabytes range work but will take a few seconds to process. You'll see a size warning for very large files rather than a silent hang.

What is the difference between btoa and TextEncoder + btoa?

btoa alone operates on JavaScript's internal UTF-16 representation and fails for characters outside Latin-1. Converting to UTF-8 bytes first with TextEncoder handles any Unicode text correctly. This tool always uses the correct path.

Does it work offline?

Yes, once the page is loaded. No network requests are made during encoding or decoding.