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 without an account, on as many payloads as you want, and there is no usage counter. The only cookies this site sets are two language cookies, and neither identifies you. 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.