Base64 Encoder & Decoder

Global tools

Base64 is how bytes travel through places that only carry text: a JSON file, an XML attribute, an email header, a URL, a CSS rule with an icon in it. This page encodes text into it, decodes it back, and handles the parts that quietly break naive implementations - the two alphabets, the optional padding, wrapped lines, and text that is not Latin-1.

The automatic mode decides from the text itself: base64 is recognized, everything else is encoded. It says which way it went in the results.

A data URL (data:image/png;base64,...) is recognized too: it is read into a media type, a byte count and a hex preview of the first bytes.

URL-safe replaces + and / with - and _ and drops the padding, which matters inside a link, a filename or a JWT.

Leave it blank for "encoded.txt".

Results update as you type. Nothing leaves your device.

Text encoded as base64

standard

44 B of text became 60 base64 characters.

Input
44 B
Output
60 B
Characters
60
Lines
1

Base64

VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4=

Copy it, or download it as a file. This is the encoding to put in JSON, an XML attribute, an email header or a data URL.

What the numbers do not say

  • Base64 is an encoding, not encryption: anybody can decode it in one step. It exists because some channels carry text rather than bytes, not because it hides anything.
  • The output is about a third longer than the input - four characters carry every three bytes - which is the price of squeezing binary into text.
  • The text is encoded as UTF-8 first, so accents, Chinese and emoji all survive the round trip. JavaScript’s own btoa() throws on them, which is one reason this page does not use it.
The text never left this browser tab: there is no request behind the page at all.

It also covers the other two wrappers that sit next to base64 in everyday work: percent-encoding, where the three common flavors disagree about what a space and a plus sign mean, and `data:` URLs, which are base64 with a header - so pasting one here tells you what format the payload really is before you do anything with it.

About this base64 encoder & decoder

Encoding bytes as text is a transport trick rather than a secret-keeping one, and this page treats the two as unrelated jobs: it converts text to base64 and back with the standard and URL-safe alphabets, reads percent-encoding, and unfolds a `data:` URL to show what its payload really is.

The conversion is arithmetic and nothing more. Three bytes become four characters because 24 bits fit exactly into four six-bit values, so the output is a third longer and never lossy; text goes through UTF-8 first, which is why an accent or an emoji survives the round trip. Everything stays local to the tab, so the string never leaves it.

Base64 is not encryption and cannot be stretched into it. Anyone holding the string can decode it in one step, with no key and no effort, so a token or a password written this way is exactly as readable as plain text. This page encodes and decodes; it does not protect.

How this base64 encoder & decoder works

What base64 is, and the one thing it is not

Base64 takes three bytes and writes them as four characters from a 64-character alphabet: A-Z, a-z, 0-9, plus `+` and `/`. Three bytes is 24 bits, and four characters hold 24 bits, so nothing is lost - the output is just longer, by exactly a third. Padding with `=` at the end makes the length a multiple of four so that a decoder knows when to stop.

It is an encoding, not encryption, and the difference matters: anybody can decode base64 in one step, with no key and no effort. It exists because some channels carry text and not bytes - not because it hides anything. A password, a token or a private key written in base64 is exactly as readable as one written in plain text, which is worth remembering before a secret goes into a URL this way.

The alphabet is why the URL-safe variant exists. `+` and `/` mean something in a query string and in a file name, so RFC 4648 defines a second alphabet that swaps them for `-` and `_` and drops the padding. JWT parts use it, and so does anything meant to travel in a link intact. Both are accepted on the way in here; the choice only affects what comes out.

Why text has to be UTF-8 first

Base64 encodes bytes, and a browser’s `btoa()` refuses anything outside Latin-1: `btoa('café')` throws, and `atob` hands back one byte per character, so an accented letter or an emoji comes out mangled. That is a character-encoding bug, not a base64 bug, and it is why this page goes through `TextEncoder` and `TextDecoder` instead - so `café`, `日本語` and `🎉` all survive the round trip unchanged.

The same care applies in the other direction: when the decoded bytes are not valid UTF-8, they are not text at all. That is what happens when you decode the base64 of a PNG or a PDF, and the useful answer is "this is a picture, not text" rather than a page full of replacement characters. This tool says which binary format it looks like, from the first few bytes.

Percent-encoding, and the plus sign that turns into a space

Percent-encoding is the older and more confusing wrapper, because "escape everything" is not one rule. Encoding a single value inside a query string has to escape `&`, `=`, `#`, `/` and everything else that would end the value or start a new parameter: that is `encodeURIComponent`. Encoding a whole URL must leave those delimiters alone or the URL stops working: that is `encodeURI`.

The third flavor is form encoding, where a space becomes `+` instead of `%20` - which is why a link copied out of a form and pasted into a document sometimes arrives with spaces turned into plus signs, or plus signs turned into spaces. Both are correct in their own context, and the setting here exists so you can see which one you have.

Worked examples

Each example below was run through the calculator on this page when the site was built, so the numbers match what you see when you enter the same inputs.

Text on its way into a JSON file

What to do: Text to base64

Encoded as base64

standard

44 B of text became 60 base64 characters.

Input: 44 B · Output: 60 B · Characters: 60 · Lines: 1

The quick brown fox becomes 60 base64 characters, about a third longer than the sentence. That is the price of turning bytes into text, and the reason base64 should not be used where plain text would do - a JSON file with a base64 blob in it is a third bigger for no gain.

A JWT part, decoded

What to do: Base64 to text · Input: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Decoded base64

text

The base64 was 36 characters and decoded to 27 B of UTF-8 text.

Input: 36 B · Output: 27 B · Characters: 27 · Lines: 1

JWT parts are base64url: - and _ instead of + and /, and no padding. This decoder accepts both alphabets, so a token part can be pasted straight in without fixing the padding first.

A query value, escaped

What to do: Text to percent-encoded (%20 style) · Input: a=1&b=2 · Percent-encoding style: A value inside a query string (%26, %3D, %2F escaped)

Percent-encoded

escaped

Escaped as a value inside a query string.

Input: 7 B · Output: 13 B · Characters: 13 · Lines: 1

In the component style the ampersand and the equals sign are escaped, because they would otherwise end the value and start a new parameter. Switch the style to "whole URL" and they are left alone - because there they are what holds the URL together.

Frequently asked questions

Is base64 a kind of encryption?

No, and it is worth being blunt about it: base64 is a reversible encoding with no key, and anybody can decode it in one step. It is used to carry bytes through text-only channels, not to hide anything. A password, an API token or a private key written in base64 is exactly as readable as one written in plain text - if anything it looks more sensitive, which is how it ends up in places it should not be.

Why is my base64 longer than the text I put in?

By design: four characters carry three bytes, so the output is four thirds of the input - about 33% longer, plus a couple of padding characters. That is the whole cost of the format. It is also why base64 is a bad choice for large files in a database or a JSON payload: a third more storage, and a third more to transfer, for a conversion that adds nothing.

Why does my accented text come out wrong in other tools?

Because base64 encodes bytes, and a lot of implementations use the browser’s `btoa`, which refuses anything outside Latin-1 or, worse, silently mangles it. `café`, `日本語` and emoji all break that way. Everything here goes through UTF-8 first, so the bytes that are encoded are the bytes the text really is - and the tests use accented, Chinese and emoji text to prove it.

What is the difference between the standard and URL-safe alphabets?

Only two characters and the padding. The standard alphabet uses `+` and `/`; the URL-safe one (RFC 4648 §5) uses `-` and `_`, and usually drops the trailing `=`. That matters because `+` means a space in form encoding and `/` ends a path segment, so a standard base64 string in a link can arrive corrupted. JWT parts, and most things meant to travel in a URL or a file name, use the URL-safe form. This tool reads both and writes whichever you choose.

Why did decoding say the bytes are not text?

Because they are not: you decoded the base64 of a picture, a PDF, a zip file or something else binary, and the bytes are not valid UTF-8. Rather than showing a page of replacement characters, this tool says so and names the format from the file signature. It also tells you what would actually help: pasting the whole `data:` URL instead, or using one of the file tools on this site if you wanted the file back.

What is a data: URL, and is it safe to paste one here?

A data URL is a file written into text: a media type, optionally `base64`, and the payload. They appear in CSS for small icons, in HTML for inline images and in JSON APIs for documents. Pasting one here is safe because nothing is sent anywhere - and useful, because this page reads the header and the first bytes and tells you what the payload really is, which is the question people usually have when they meet a 40,000-character string that starts with `data:image/png;base64,`.

Why did my plus sign turn into a space?

Because the string was form-encoded rather than URL-encoded. In `application/x-www-form-urlencoded` data a space is written as `+`, so a decoder that assumes that convention turns every `+` it sees into a space - including the `+` characters of standard base64. The fix is either to use the URL-safe alphabet in the first place, or to percent-encode the base64 before putting it in a form. The percent-encoding style setting on this page is the same distinction, made visible.

Can I decode base64 straight out of a file?

Not on this page: it takes text, pasted or typed. A `.b64` or `.txt` file works by opening it and copying, and if what you have is a base64 image inside a JSON API response, pasting it here is usually how you find out what it is. The file tools on this site are the ones that turn bytes back into downloadable files.

Assumptions and sources

  • Base64 follows RFC 4648: the standard alphabet with `+`, `/` and `=` padding, and the URL-safe alphabet with `-` and `_`.
  • Three escape styles are offered because URLs have three jobs: a value inside a query string, a whole URL, and form data, where a space becomes `+`.
  • Everything is converted in this tab, and nothing is uploaded. Base64 is encoding rather than encryption, so it hides nothing.

Last reviewed 2026-09-16. Runs locally on your device; keep backups; no financial advice applies. Read the full disclaimer.

Where a figure on this page comes from an official agency — HUD, IRS, FICO or a state body — the site keeps a dated snapshot of the source page in its sources library, and a scheduled job re-checks that snapshot, so the number can be traced back to the document it came from.