Base64 Encoder & Decoder

Paste text to encode or base64 to decode. The direction is detected automatically, non-ASCII text survives the round trip, and binary output is shown as a hex dump instead of a screenful of replacement characters.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Convert. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

URL-safe base64

The - and _ variant with no padding, which a standard decoder rejects

aGVsbG8_d29ybGQ

Standard base64

Ordinary padded base64 decoded back to text

aGVsbG8gd29ybGQ=

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Using standard base64 in a URL

    + and / are not URL-safe and get percent-encoded or mangled by proxies.

    Instead:Use the URL-safe alphabet with - and _, which is what JWTs use.

  2. Assuming base64 is encryption

    It is an encoding with no key. Anyone can decode it instantly.

    Instead:Encrypt if the content is sensitive. Base64 only makes bytes transport-safe.

  3. Rejecting unpadded input

    URL-safe base64 usually drops the = padding, and a strict decoder fails on it.

    Instead:Pad to a multiple of four before decoding, or use a decoder that tolerates it.

What makes this one different

Base64 is four lines of code, and most tools online still get two things wrong.

Non-ASCII actually works

Text is encoded to UTF-8 bytes first. Tools built directly on the browser's btoa throw an exception on anything outside Latin-1, which is why the same string sometimes fails elsewhere. Decoding uses strict UTF-8, so accented characters come back as themselves rather than as mojibake.

Binary is shown as binary

If the decoded bytes are not valid UTF-8, you get an offset hex dump rather than replacement characters that look like corruption. Common file signatures are recognised too, so a PNG or a PDF or a DER certificate is named.

Both alphabets

Standard base64 uses plus and slash; the URL-safe variant in RFC 4648 uses dash and underscore, usually without padding. Decoding accepts either, encoding shows both, and the verdict says which one your input used.

It notices a JWT

A JWT is three base64url segments joined by dots. Decoding it as one value gives you the header followed by noise, so the tool points you at the JWT decoder instead of pretending it worked.

What is base64, and why is it not encryption?

Base64 solves one narrow problem: moving arbitrary bytes through a channel that only reliably carries text. Email headers, JSON string values, URLs, YAML fields and HTTP headers all mangle raw binary. Base64 re-expresses those bytes using 64 characters that survive the trip.

Three bytes in, four characters out

The encoder takes 24 bits at a time and splits them into four 6-bit groups, because 2 to the power of 6 is 64: one character per group. That is the entire algorithm, and it is why base64 always costs about a third more size than the input. When the input does not divide into three, the last group is padded with = so the length stays a multiple of four.

"Man"  ->  01001101 01100001 01101110    3 bytes, 24 bits
           ->  010011 010110 000101 101110  4 groups of 6
           ->     19     22      5     46   as numbers
           ->      T      W      F      u   via the alphabet

"Man" encodes to TWFu: 3 bytes became 4 characters

It is not encryption, and it is not a hash

There is no key and no secret. Anyone can decode it, as this page demonstrates in one click. A base64 string in a config file, an environment variable or a Kubernetes Secret protects nothing at all: it only stops the bytes from breaking the format they are sitting in. If a value needs to be secret, it needs encryption or a secret manager; encoding is not a security control in any sense.

Two alphabets, and why decoders disagree

Standard base64 uses + and / for the last two characters. Those both have meaning inside a URL, so RFC 4648 defines a URL-safe variant using - and _ instead, usually with the padding dropped. JWTs use the URL-safe form. A decoder expecting one alphabet will reject the other, which is the usual cause of a value that works in one tool and fails in another.

standard   TWFu+/A=      + and /, padded to a multiple of 4
url-safe   TWFu-_A       - and _, padding usually dropped

same bytes, and a strict decoder accepts only one of them

Where the UTF-8 bug comes from

Base64 operates on bytes, but the browser's built-in btoa takes a string and throws on any character above U+00FF. Tools built directly on it fail on accented text, and naive decoders turn café into café. The fix is to convert text to UTF-8 bytes before encoding and decode strictly afterwards, which is what this page does, so a round trip returns exactly what you put in.

More encoding tools

Unix Timestamp Converter Seconds or milliseconds? It says which JWT Decoder & Inspector Read the claims, and what is wrong with them URL Encoder and Decoder Which of the two functions you actually want HTML Entity Encoder and Decoder Five characters, not four hundred Hex Encoder and Decoder Bytes, with a hex dump Base32 Encoder and Decoder Two alphabets that decode differently String Escape Converter Six targets, one of them injection Punycode and IDN Converter The domain that is not what it looks like

Elsewhere on the site

Terraform Validator & Formatter Kubernetes YAML Generator Kubernetes YAML Validator AWS IAM Policy Validator & Analyzer