utilyfe

Base64 Encoder and Decoder

Turn text into Base64 and back, including emoji, URL-safe values and data URLs.

Runs entirely in your browser. Nothing you enter is uploaded or stored.

Also try:JSON FormatterURL Encoder and DecoderJWT Decoder

How to use the Base64 Encoder and Decoder

  1. 1Choose Encode or Decode.
  2. 2Paste your text or your Base64 into the box.
  3. 3For encoding, tick URL-safe if the value goes in a URL or a JWT, or Wrap at 76 characters for email and PEM formats.
  4. 4Press Copy to take the result. The box above keeps what you pasted.

What Base64 is for

Some places can only carry plain text: the body of an email, a JSON string, a URL, an HTTP header, a YAML file. Base64 takes any run of bytes and rewrites it using 64 characters that survive those places unharmed: A–Z, a–z, 0–9, + and /, with = as padding at the end.

Every 3 bytes become 4 characters, so the result is about a third larger than what you started with. That’s the price of safe passage.

You’ll meet it in data URLs, in email attachments, in the middle of a JWT, and in config files where a certificate or key has to sit inside a text field.

It’s encoding, not encryption

Base64 hides nothing. The value can be read back by anyone, with no key and no password. A “Base64-encoded” API key in a config file is a plain-text API key with extra steps.

Use it to move bytes through a text-only channel. Don’t use it to keep a secret.

UTF-8, emoji and the btoa trap

Browsers have a built-in btoa, but it only takes characters up to code point 255. Hand it an emoji, or Chinese text, and it throws InvalidCharacterError. That’s why some online encoders quietly mangle non-English text.

The fix is to decide how the text becomes bytes before encoding, and UTF-8 is the answer everywhere else in computing. This page always uses UTF-8:

Text Bytes Base64
hi 2 aGk=
hé 3 aMOp
👍 4 8J+RjQ==

A single emoji takes four bytes, which is why one character can turn into eight Base64 characters.

URL-safe Base64

Inside a URL, + means a space to some parsers, / separates path segments, and = has to be escaped. URL-safe Base64 uses - and _ in their place and leaves the padding off. It’s what the three parts of a JWT use.

Tick URL-safe when encoding. When decoding, you don’t need to say which alphabet you have: both are accepted, and a note tells you what was recognised.

Padding, whitespace and line length

  • Padding is the = at the end, bringing the length to a multiple of four. Missing padding is added here automatically.
  • Whitespace is ignored when decoding, so a value copied out of a terminal or a YAML file with line breaks in it still works.
  • Line wrapping matters when the value goes into an email or a PEM file: those formats expect lines of 76 characters. Tick Wrap at 76 characters if you need that; leave it off for URLs, JSON and headers.

Data URLs

A data URL packs a whole file into a link:

data:image/png;base64,iVBORw0KGgoAAA…

If you paste one to decode, the data: prefix is removed for you. Text-based types like text/plain or image/svg+xml come back readable; a PNG or a PDF is raw bytes, so you’ll get a note saying how many bytes were found rather than a boxful of noise.

Questions

Is Base64 a way to hide or encrypt data?
No, and this is the most common mistake made with it. Base64 is a reversible format, not a cipher: anyone who has the value can decode it in seconds, including on this page. Never use it to protect a password, a token or personal data.
Why does my emoji or accented text break in other Base64 tools?
The browser's built-in btoa function only accepts characters up to code point 255, so an emoji makes it throw an error. Some tools work around it by mangling the text. This page converts your text to UTF-8 bytes first, which is what every server and library expects, so emoji and accents survive a round trip.
What's the difference between the URL-safe version and normal Base64?
Standard Base64 uses + and /, which have their own meaning inside a URL, and = padding, which has to be escaped. URL-safe Base64 swaps those for - and _ and drops the padding. JWTs use it for exactly that reason. Decoding here accepts either without being told which.
Do I have to add the = signs at the end?
No. If the padding is missing, it's added for you and a note says so. That's the usual reason another tool refuses a value that looks fine.
Can I decode an image or a PDF here?
You can paste one, but the result won't be readable text. When the bytes aren't valid UTF-8, the page says how many bytes it found instead of filling the box with rubbish. For images, save the data: URL to a file instead.