Tooltrusty

Base64 Encoder & Decoder

Correct Unicode handling in both directions — which is where most Base64 tools fall over.

0 BInput
0 BOutput
—Change

Runs in your browser. Everything you type or load here is processed locally by JavaScript on this page. Nothing is uploaded to Tooltrusty or to any third party.

What the base64 Encoder & Decoder does

Base64 encodes arbitrary binary data using 64 printable characters, so it can travel through systems that only handle text — email bodies, JSON fields, URLs, HTTP headers, configuration files. Three bytes of input become four characters of output, which is why encoded data is always about 33% larger than what went in.

The detail that separates a correct implementation from a broken one is Unicode. JavaScript's built-in btoa function only accepts characters in the range 0–255, so calling it on text containing é, 日 or an emoji throws an error — and many online tools respond by silently mangling the text instead. This tool encodes to UTF-8 bytes first using TextEncoder, then Base64-encodes those bytes, and reverses the process exactly on the way back. Accented Latin, CJK, Arabic, emoji and everything else round-trips correctly.

Two variants are supported. The URL-safe alphabet replaces + and / with - and _ and drops the = padding, because those three characters have special meanings in URLs and query strings; this is the encoding used in JSON Web Tokens. 76-character wrapping is the MIME convention for email attachments. The decoder accepts either variant automatically, restoring padding as needed, so you can paste in whatever you have found.

One thing Base64 is not: a security measure. It is trivially reversible — this page proves it in one click. Anything genuinely sensitive needs encryption, not encoding.

How to use it

  1. Choose Encode or Decode.
  2. Paste your text or your Base64 string into the left box; the result appears live on the right.
  3. Tick URL-safe if the value is going into a URL, a query string or a JWT.
  4. Copy the output, or press Send output to input to verify a round trip.

A worked example

Encoding text that contains non-ASCII characters:

Input:  Tooltrusty — café, 日本語 ✅
Output: VG9vbHRydXN0eSDigJQgY2Fmw6ksIOaXpeacrOiqniDinIU=

The input is 27 characters but 38 UTF-8 bytes, because the em dash, the accented é, the three Japanese characters and the emoji each take two to four bytes. The output is 52 characters — the expected four-for-three ratio plus padding. Decoding it returns the original string exactly, emoji included.

A tool that used btoa directly on this string would either throw an error or produce output that decodes to mojibake. If you have ever seen café come back out of a Base64 round trip, that is the bug.

Frequently asked questions

Why is my Base64 longer than the original text?

By design. Four output characters represent every three input bytes, an increase of roughly 33%, plus padding. That is the fixed cost of representing binary data in a restricted text alphabet.

Is Base64 encryption?

No. It is an encoding with no key and no secret — anyone can decode it instantly. It solves the problem of transporting binary data through text-only channels, and offers no confidentiality at all.

What is URL-safe Base64?

A variant that swaps + for - and / for _, and usually drops the = padding, because those characters have reserved meanings in URLs. It is what JSON Web Tokens use. This decoder accepts both variants automatically.

Why does decoding produce strange characters?

Usually because the original data was not UTF-8 text — it might be an image or a compressed file, which will look like nonsense when interpreted as text. It can also mean the Base64 was truncated or had characters inserted by line wrapping in an email client.