Base64 encode

Type or paste anything and get its Base64 encoding as you go. Base64 exists to move bytes through channels that only accept a narrow set of characters, which is why it turns up in data URIs, mail attachments and authorisation headers rather than anywhere a human was meant to read it. Nothing you type is uploaded — the encoding happens in this page.

Use URL-safe when the result goes into a path, a query parameter or a JWT.

Result

The answer appears here as you type.

  • Where it runs

    Nothing is uploaded, because there is no file — it is worked out in this page.

  • No queue, no account

    It answers as fast as your machine can, and it never asks who you are.

  • As often as you like

    Nothing is counted and nothing is capped — answering again costs us nothing.

How it works

  1. Paste or type your text into the box. The result appears as you type.
  2. Choose the alphabet. Standard is right almost always; URL-safe is for anything going into a URL or a JWT.
  3. Copy the result. Nothing was uploaded and nothing was stored.

It is not encryption, and the difference matters

Base64 is a way of writing bytes down, not a way of hiding them. There is no key, nothing is secret, and anyone holding the result can read it back in a second — which is the whole point, since the receiving end has to. Calling it "encoded" rather than "encrypted" is not pedantry; it is the difference between a transport format and a security measure.

This matters in one specific place: the `Authorization: Basic` header, which is a username and password joined by a colon and Base64-encoded. That is not protection of any kind, and it is why Basic auth over plain HTTP is equivalent to sending the password in the clear. Over HTTPS it is fine, because TLS is doing the actual work.

Three bytes in, four characters out

The algorithm takes the input three bytes at a time — twenty-four bits — and re-cuts them into four groups of six, each of which indexes a 64-character alphabet. Six bits index sixty-four values exactly, which is where the name comes from and why the alphabet is that size rather than a rounder one.

The consequence is a fixed cost: the output is always about a third larger than the input, plus padding. A 3 MB image inlined as a data URI becomes 4 MB of markup. That is the price of the guarantee, and it is why Base64 belongs in headers, small payloads and anywhere text is mandatory, and not in front of a file that could simply have been uploaded as bytes.

When to switch to the URL-safe alphabet

The standard alphabet ends in `+` and `/`. Both mean something else inside a URL — `+` is a space in a query string, `/` is a path separator — so a Base64 value dropped into a URL either breaks or is silently altered by whatever handles it next. RFC 4648 §5 defines the fix: `-` and `_` instead, and the trailing `=` dropped because it is a reserved character too.

This is what JWTs use. Every segment of a token is URL-safe Base64 with no padding, which is also why so many decoders reject them: a decoder that insists on padding rejects every real token it is handed. The one on this site restores the padding before decoding, so it does not care.

Non-ASCII text is where implementations go wrong

Base64 encodes bytes, and a string is not bytes until you decide on an encoding. Get that step wrong and everything still appears to work, because every implementation agrees on ASCII — the bug is invisible until somebody types a name with an umlaut in it.

The classic failure is JavaScript's own `btoa`, which throws outright on anything above U+00FF, and the classic workaround is worse: converting with `charCodeAt` gives one byte per code unit, so `ü` becomes `FC` where the file on disk holds `C3 BC`. This page encodes UTF-8 throughout, which is why "Grüße" round-trips and why that string, rather than "hello", is what its tests are written against.

Where you will actually meet it

Data URIs, so a small icon can live inside a stylesheet instead of costing a request. MIME, so an attachment survives a mail server that predates 8-bit transport. Basic authentication headers. JWT segments. PEM files, which are DER bytes in Base64 between two dashed lines. Kubernetes secrets, which are Base64 in YAML and are the reason a lot of people first look this up.

What these have in common is a channel that was specified for text and is being asked to carry something else. Base64 is the adapter. Where the channel is happy with bytes — a file upload, a request body — it adds a third to the size and buys nothing.

Base64 encode: common questions

Is my text uploaded to be encoded?

No. The encoding runs in this page, on your machine, and you can confirm that in the network panel — nothing is sent while you type. That matters here more than on most tools, because the strings people Base64-encode are routinely passwords and tokens.

Why does the result end in one or two equals signs?

That is padding. The algorithm works on three bytes at a time, so when the input length is not a multiple of three the last group is short and is padded to four characters with `=`. One equals sign means two bytes left over, two means one. The URL-safe option drops them, because `=` is reserved in a URL.

Does Base64 make my data secure?

No, and treating it as though it does is a real and common mistake. There is no key and nothing is hidden — anyone who has the result can decode it instantly, by design, because the receiving end has to be able to. If you need secrecy you need encryption, which is a different thing entirely.

Can I encode a file rather than text?

Not on this page, which is built for strings. For a file, what you almost always want is a data URI — the Base64 with a MIME type in front of it — and for the sizes involved that belongs in a build step rather than a text box. A 3 MB image becomes 4 MB of Base64, which no browser enjoys pasting.

Is there a limit on the length?

Only your own machine. Nothing is queued or metered, because there is no server doing the work. Very long inputs will make the tab think for a moment; the encoder chunks its work specifically so that a large paste does not overflow the call stack, which is the failure the naive one-line implementation has.

Other tools