A Base64 encoder that never sees your input.
Convert text or files to Base64 and back, with UTF-8 safety and a URL-safe variant for use in JWTs, query strings, and headers. The encoder, the decoder, and the file reader all run in this browser tab — your bytes never reach a server.
0 bytesYour input never leaves your machine. The encoder, the decoder, and the file reader all run in this browser tab using the built-in `TextEncoder`, `TextDecoder`, `btoa`, `atob`, and `FileReader` APIs. We never see your text or files, and the page makes no network calls related to your input.
UTF-8 safe encoding, and the variants that actually matter.
The Base64 features people reach for — full Unicode round-trip, URL-safe variant, file mode — surfaced without sign-up, without ads, and without dropping your bytes on a server.
Emoji, accented characters, and CJK round-trip cleanly. Naïve `btoa(str)` fails on any code point above 0xFF — this encoder pipes through `TextEncoder` first, so the whole Unicode range works without manual escaping.
Switch between standard Base64 (`+`, `/`, `=`) and URL-safe Base64 (`-`, `_`, no padding) — the variant used in JWTs, OAuth state, and any query-string payload that fears percent-encoding.
Decoding accepts either variant, with or without padding, and tolerates whitespace and newlines. Paste output from any tool — `openssl base64`, `base64url`, hand-trimmed JWT segments — and it just works.
Drop a file (image, PDF, anything under 5 MB) to get its Base64 representation — useful for embedding small assets as `data:` URLs or stuffing binary into JSON. Reads via `FileReader`; bytes never leave the page.
Every keystroke triggers a re-encode or re-decode. No Generate button, no spinner — just immediate output, even on inputs at the 5 MB ceiling.
On decode failure, the engine surfaces the exact problem — invalid character, length not multiple of 4, malformed padding. You see what `atob` would throw, in plain English.
One click for the system clipboard or a `.txt` file. The clipboard mirrors whatever is currently in the output pane; the download saves the same.
Use it anonymously, on as many payloads as you want. No account, no cookies, no usage counter. Inspect the network tab — there is nothing outbound to inspect.
Wherever bytes need to travel as plain ASCII.
Convert a 4 KB favicon, SVG, or sprite into a `data:` URL so it ships inside the HTML instead of as a separate request. Saves a roundtrip on the critical path.
A JWT is three URL-safe Base64 strings joined with dots. Decode the second segment to see the payload claims — useful when the decoder tool is overkill and you just want a quick peek.
Encode `user:password` as standard Base64 and prepend `Basic ` — that is the entire spec for the `Authorization` header in HTTP Basic. Handy for one-off curl calls before reaching for a proper client.
JSON has no native binary type, so files, certificates, and protobuf payloads travel as Base64 strings. Encode locally before constructing the payload; decode at the receiving end.
Shells, CI systems, and config managers choke on raw binary or multi-line strings. Base64 collapses the input to a single ASCII line that survives any quoting, splitting, or env-var stuffing.
WebSocket handshakes require a random 16-byte key encoded as standard Base64. Generate the bytes elsewhere, encode them here, and paste the result into the `Sec-WebSocket-Key` header.
Base64 encoding, the plain answers.
No. Base64 is an encoding, not an encryption — anyone can decode it instantly without a key. It exists to transport bytes through systems that only allow ASCII (email, URLs, headers, JSON). If you need confidentiality, encrypt first and then Base64 the ciphertext.
Standard Base64 uses `+`, `/`, and `=`, all of which get percent-encoded inside URLs and form fields. The URL-safe variant swaps them for `-`, `_`, and no padding — the result fits into a URL, a JWT, or an OAuth state parameter without further escaping. JWTs use it everywhere by spec (RFC 7515 §3).
Because we encode the string to UTF-8 bytes first via `TextEncoder` before handing it to `btoa`. Raw `btoa(str)` walks the input as 16-bit code units and throws on anything above 0xFF — which includes every emoji, every CJK character, and several accented Latin letters. The two-step pipeline (text → UTF-8 bytes → Base64) is the standard fix.
No. Every byte of the pipeline runs in this browser tab — the encode/decode, the file read, the variant conversion. The page makes no network calls related to your input. Open DevTools → Network while you paste, and nothing outbound appears.
Inputs above 5 MB are rejected to keep the live preview responsive — Base64 inflates by ~33%, so a 5 MB input produces a ~6.7 MB output, and the UI starts to feel sluggish past that. For larger payloads use a command-line tool like `base64` or `openssl base64`.
Yes — drop any file under 5 MB into the file strip and the tool reads it with `FileReader.readAsArrayBuffer`, then Base64-encodes the bytes. Output is plain ASCII text you can paste into a JSON field, a `data:` URL, or anywhere else. The file is read locally; nothing is uploaded.
Shipping APIs that handle the actual binary?
Sign up for the free tier and you get $100 in credits, plus VMs, managed databases, object storage, and zero-config autoscaling across four regions.