PacketNebula

Base64 Encoder / Decoder

Base64, Base64url, URL and hex, fully UTF-8 safe, with files and auto-detect.

100% in your browser. Nothing you type ever leaves this page.

The Unicode trap every developer hits once

The browser's built-in btoa() throws on anything outside Latin-1, and the classic workaround mangles accents into é sequences. The correct pipeline, and the one this page uses, is text to UTF-8 bytes first (TextEncoder), then bytes to Base64. Same thing in reverse for decoding. That is why "héllo" encodes to aMOpbGxv here and survives the round trip, emoji included, while half the encoder sites on the internet quietly corrupt it. The spec for the alphabet and padding lives in RFC 4648; the Unicode handling is the part everyone improvises, badly.

What the auto-detect actually does

Paste an unknown blob in the encoded pane and click auto-detect. The tool tries, in order: hex (even length, only hex digits), Base64url (presence of - or _), standard Base64, then percent-encoding (presence of %xx sequences). The first candidate that decodes cleanly wins, and the mode buttons update so you can see what it concluded. It will not guess compressed or encrypted content: if the decoded bytes are not valid UTF-8 text, the tool says so and offers the bytes as a file download instead of printing garbage.

Files and data URIs, both directions

"Encode a file" reads any file locally and produces its Base64, optionally with the data:mime;base64, prefix ready to paste into a CSS background-image, an HTML img src or an API payload. Keep the 4/3 size inflation in mind: inlining a 5 KB icon is a fine way to save a request, inlining a 300 KB photo is how a page gets slow. The reverse direction matters more often than people expect: paste Base64 from an API response or an email source, and if it turns out to be a PDF or an image, the download button hands you the file.

Where each mode earns its place

Base64 carries binary through JSON APIs, basic auth headers and MIME email. Base64url is the dialect of JWTs and anything that lives in a URL path; if you work with tokens, our JWT decoder applies it on every segment. Percent encoding belongs to query strings: it is the difference between ?q=a&b breaking your parameters and ?q=a%26b passing them intact. Hex is the debugging mode: two characters per byte, painless to read in a packet capture or a checksum, which is also why our hash generator speaks it natively.

Frequently asked questions

Why does my decoded Base64 show weird characters like é?

That is mojibake: the text was encoded as UTF-8 but decoded as if it were Latin-1, which is exactly what the browser's raw atob() does. This tool decodes through a proper UTF-8 decoder, so accents and emoji survive the round trip. If you still see garbage, the original data was probably not UTF-8 text at all but binary.

Is Base64 a form of encryption?

No. Base64 is a reversible re-spelling of bytes as text, with no key and no secrecy: anyone can decode it instantly, including this page. Use it to transport binary data through text-only channels. If you need confidentiality, you need actual encryption, and Base64 of a password in a config file protects nothing.

What is the difference between Base64 and Base64url?

Two characters and the padding. Standard Base64 uses + and /, which break inside URLs and filenames, so Base64url (RFC 4648 section 5) replaces them with - and _ and usually drops the trailing = padding. JWTs, WebAuthn and most URL-embedded tokens use the url variant; decoders that reject a JWT segment are often just choking on the missing padding.

When should I use URL encoding instead of Base64?

URL (percent) encoding escapes the few characters that have special meaning in a URL while keeping the rest readable: it is for putting text into query strings. Base64 is for putting arbitrary bytes into text. If a human should still read the value in the address bar, percent-encode it; if it is binary or you do not care about readability, Base64url it.

How much bigger does Base64 make my data?

Exactly 4/3, plus padding: every 3 input bytes become 4 output characters, so a 300 KB image becomes a 400 KB string. That overhead is why inlining large images as data URIs hurts page weight, and why email attachments (Base64 under the hood in MIME) are bigger than the files themselves.