Base64 Encoder & Decoder
Encode and decode Base64 or Base64URL with full Unicode support, turn a file into a data URI, and decode binary Base64 back to a file. Nothing is uploaded.
Plain text
Base64
Result appears here as you type.
File to data URI
images, fonts, anythingFiles are read locally in this tab — nothing is uploaded.
About the Base64 Encoder & Decoder
Base64 represents arbitrary bytes using 64 printable ASCII characters, so binary data can travel through channels that only accept text — HTTP headers, JSON string fields, email bodies, data URIs, git patches. It is an encoding, not encryption: anyone can decode it in one step, and it makes data roughly 33% larger, since every three input bytes become four output characters.
You will run into Base64 constantly without choosing it: it is how HTTP Basic Auth credentials are carried in an Authorization header, how the header and payload segments of a JWT are packed, how images get inlined as data: URIs in CSS and HTML, and how binary attachments survive being embedded in JSON, XML or MIME email. Recognizing it on sight — a run of letters, digits, +, / and trailing = padding — is a basic debugging skill.
This converter handles the full Unicode range in both directions, which naive implementations do not. The browser's built-in btoa() throws on any character above U+00FF, so it breaks on emoji, accented letters and CJK text the moment you try to encode them directly. Here the input is converted to UTF-8 bytes first, so "héllo 👋" round-trips correctly instead of throwing InvalidCharacterError.
It also supports Base64URL — the padding-free variant that swaps + and / for - and _ — which is what JWTs, OAuth state parameters, and any other value embedded directly in a URL use. Standard Base64's +, / and = characters all have special meaning inside a URL and would otherwise need percent-encoding on top, which is exactly the problem Base64URL exists to avoid.
To encode a file rather than text, use the file button: pick an image, font, PDF or any other binary and you get back a complete data: URI, prefixed with the media type your browser reports for that file — usually derived from its extension, and application/octet-stream when it cannot tell — ready to paste into CSS, an img src, or a JSON field. The file is read in the page with the File API — it is not uploaded, which is worth knowing before you encode anything you would not email. Bear the size in mind: encoding adds about a third, so a 300 KB image becomes a 400 KB string, and inlining anything much larger than a small icon usually costs more than the request it saves.
- Unicode-safe encoding and decoding via UTF-8, including emoji and CJK — no InvalidCharacterError on non-Latin1 input
- Standard Base64 and URL-safe Base64URL, with padding handled automatically
- Swap button to feed the output straight back in as input, to confirm a round-trip in two clicks
- File to data URI conversion for images, fonts, PDFs and other binaries, read entirely in-tab
- Decoding back to a file: binary Base64 downloads as PNG, JPEG, GIF, WebP, PDF, ZIP or gzip, identified from its first bytes
- Live byte-size readout on both panes, so you can see the ~33% size cost of encoding as you type
- Nothing leaves your browser — no network request is made for any input, text or file
How to use it
- Choose a direction: Text → Base64 to encode, or Base64 → Text or File to decode.
- Paste your content into the left pane; the result appears immediately on the right as you type.
- When encoding for a URL or a JWT, tick URL-safe to get the - and _ alphabet without padding.
- To convert a file — an image, font or any other binary — use Choose file and copy the resulting data: URI.
- To go the other way, paste a data: URI or a bare Base64 string into the decoder. If it is not text, the panel reports the type and size and offers a Download button.
- Press Swap to move the output into the input and reverse the direction — useful for confirming a round-trip or continuing a chain of transformations.
Real-world use cases
Backend & API developers
Decode the Authorization: Basic header your framework's HTTP client sent to confirm the exact credentials on the wire, or build a data: URI for a small binary payload without writing a script for a one-off check.
Frontend developers
Turn a small icon, font or SVG into a data: URI to inline directly in CSS or an <img src>, avoiding an extra network request for assets too small to be worth their own file.
QA & test engineers
Decode a Base64 fixture or captured request body from a bug report to read the actual payload, instead of squinting at an opaque string in a ticket or HAR file.
DevOps & platform engineers
Decode a Kubernetes Secret's data field, a base64-encoded CI/CD environment variable, or a Docker Compose value that arrived pre-encoded, without dropping to a terminal for a single base64 -d.
Security & AppSec engineers
Peel back Base64 layers in a suspicious payload, cookie or JWT segment during triage — while remembering, as the FAQ below stresses, that Base64 provides zero confidentiality on its own.
Examples
Encoding text
hello world
aGVsbG8gd29ybGQ=
The trailing = is padding to a multiple of four characters. Base64URL omits it.
Basic authentication header
demo:s3cret
Authorization: Basic ZGVtbzpzM2NyZXQ=
Base64 provides no security here whatsoever — Basic auth is only safe over HTTPS, because the credentials are trivially recoverable from this string.
URL-safe output
subjects?/all
c3ViamVjdHM_L2FsbA
Standard Base64 would produce c3ViamVjdHM/L2FsbA==, whose / and = characters need escaping inside a URL. Base64URL avoids that entirely.
Decoding a JWT segment
eyJhbGciOiJIUzI1NiJ9
{"alg":"HS256"}This is the header segment of a JWT, which is just Base64URL-encoded JSON. Paste any JWT segment here to inspect it, or use the dedicated JWT Decoder for the full token including signature verification.
Common errors
| Message | Cause | Fix |
|---|---|---|
| InvalidCharacterError: Failed to execute 'atob' | The input contains characters outside the Base64 alphabet — often a stray newline, quote or an already-decoded string. | Remove surrounding quotes and whitespace. If the string uses - and _, it is Base64URL and must be converted first. |
| InvalidCharacterError: Failed to execute 'btoa' | Encoding a string containing characters above U+00FF with the raw browser API. | Convert to UTF-8 bytes first with TextEncoder. This tool does that automatically. |
| Decoded output is mojibake | The bytes were decoded as the wrong character set, usually Latin-1 instead of UTF-8. | Decode as UTF-8. If the source really was Latin-1, re-encode it correctly at the source. |
| Invalid base64 padding / length | The string was truncated, or padding was stripped by a URL-safe encoder. | Pad the string with = until its length is a multiple of four. This tool applies that automatically. |
| "Decoded bytes are not valid UTF-8 text" | The Base64 you pasted represents binary data — an image, font or other non-text file — so there is no string to show. This is no longer an error state. | Nothing to fix: the panel switches to reporting the file's type and size, and a Download button appears. If the type reads application/octet-stream, the first bytes matched no signature the tool knows and it will save as .bin, which you can rename. |
Frequently asked questions
›How do I encode a file to Base64?
Press Choose file and pick it. The file is read in your browser and you get a complete data: URI back — the MIME type, then the Base64 payload — which you can paste into CSS, an <img src>, or a JSON field. If you want the raw Base64 without the data:…;base64, prefix, delete everything up to and including the comma. Nothing is uploaded, so this works offline and on files you would not want to send anywhere.
›Is Base64 the same as UTF-8?
No, and they operate at different layers, which is why the two get tangled. UTF-8 is a way of turning characters into bytes. Base64 is a way of turning bytes into printable ASCII. Encoding text here runs both in order: your text becomes UTF-8 bytes, and those bytes become Base64. Decoding reverses it. That is also why the browser's own btoa() fails on anything above U+00FF — it skips the UTF-8 step and tries to treat each character as one byte, which emoji and accented letters are not. If a decoded string comes out as mojibake elsewhere, the usual cause is the other end interpreting the bytes as Latin-1 rather than UTF-8.
›Can I decode Base64 back into a file?
Yes. Switch to Base64 → Text or File and paste either a data: URI or a bare Base64 string. If the bytes are not valid UTF-8 text, the tool stops trying to show them as text and offers them as a download instead. A data: URI states its own media type, so the filename follows from that; for a bare string there is no type to read, and the first bytes are checked against the signatures for PNG, JPEG, GIF, WebP, PDF, ZIP and gzip. Anything else downloads as .bin — that means unidentified, not corrupt, and renaming it is enough.
›Is Base64 encryption?
No. It is a reversible encoding with no key involved — anyone can decode it in one step. Never use it to protect passwords, tokens or personal data; it provides zero confidentiality.
›What is the difference between Base64 and Base64URL?
Base64URL replaces the + and / characters with - and _, and usually drops the = padding. Those substitutions matter because +, / and = all have special meaning inside URLs and would otherwise need percent-encoding. JWTs, OAuth state parameters and most URL-embedded tokens use Base64URL specifically because of this.
›Why does Base64 make my data bigger?
Every three bytes become four characters, so the encoded form is about 33% larger, plus any padding. That overhead is the cost of representing arbitrary binary data in a text-only channel — it's not a bug in this tool, it's inherent to the encoding.
›Can I convert Base64 to an image?
Both directions work. Going in, the file panel reads an image and produces a complete data: URI you can drop straight into an <img src> or a CSS url(). Coming back out, paste the Base64 — with or without the data: prefix — into the decoder and download it: PNG, JPEG, GIF and WebP are all recognised from their first bytes, so the file saves with the right extension even when the string carries no media type of its own.
›Does this work with emoji and non-English text?
Yes. Input is converted to UTF-8 bytes before encoding, so emoji, accents and CJK characters round-trip exactly. The browser's own btoa() would throw InvalidCharacterError on all of these.
›Is my data uploaded anywhere?
No. Encoding, decoding and file reading all happen locally in your browser tab. There is no server involved, so credentials, internal payloads and unreleased assets are safe to paste or drop here.
›Why do I see = signs at the end of some Base64 strings but not others?
The = characters pad the output to a multiple of four characters, which standard Base64 requires. Base64URL — used by JWTs and URL parameters — conventionally omits this padding, since the decoder can reconstruct it from the string's length.
›Is there a size limit on what I can encode or convert?
Text encoding and decoding handle anything you can reasonably paste into a browser tab. The file converter is bounded by available memory, since the whole file is read and base64-encoded in the tab — for very large files (hundreds of MB+), a command-line tool like base64 or openssl will be faster and lighter.
Last updated