Base64 encoder and decoder
Encode text or files to Base64 and decode it back, in standard or URL-safe form. Everything runs in your browser: nothing is uploaded.
By using these tools you accept the Terms and the Privacy page.
How the Base64 encoder and decoder work
This Base64 encoder and decoder converts UTF-8 text and files to Base64 and back, in the standard alphabet or the URL-safe Base64URL one. It is for developers and admins who need to read an encoded value, build a data: URI or find out why a string won’t decode. Errors say what is wrong and where, so you can fix the input instead of guessing.
Three ways to use it
In the Text tab, encoding works from the UTF-8 bytes of what you type and shows the character and byte counts. Decoding reads Base64 back to text. Swap moves the result into the input and flips the direction, a quick round-trip test.
The File tab encodes a file, chosen or dropped anywhere on the page, twice: as plain Base64 and as a data: URI for HTML, CSS or JSON. The URI uses the media type your browser reports for the file, or one recognized from its first bytes, and is always standard Base64 on one line. The page also shows how much larger the encoded text is than the file.
Each input is read in a single pass with no server involved, so a 50 MB paste is decoded in about a second. From 2 million characters (or a 2 MB file) on, a “Decoding…” or “Encoding…” line shows first.
How strict decoding works
The decoder follows RFC 4648, sections 4 and 5. In Detect mode it accepts either alphabet. Choose Standard only or Base64URL only to check text for a system that accepts just one: the first character from the other alphabet is reported with its position. Beyond bad characters, it stops at these problems:
- An
=in the middle of the text, followed by more characters. - More than two
=at the end. - The wrong number of
=for the length, or padding on text that is already a multiple of 4 characters. - A last group of only one character, which means a character was lost or added.
- A
data:URI whose header has no;base64.
Reading the decoded result
Under the result, the page lists the alphabet it found (standard, Base64URL, or “either” when the text has none of + / - _), whether padding was present, the decoded size in bytes and, for a data: URI, its media type.
A non-canonical ending warning means the last character carries leftover bits that no encoder sets. Most decoders ignore them, but strict ones reject the input. Re-encoding the decoded result gives the canonical form.
When the bytes aren’t text, you get a download button, a preview for PNG, JPEG, GIF and WebP images, and a hex dump of the first 256 bytes, which is often enough to tell what the data is.
Options and next steps
- Padding is on by default for standard Base64. Picking the Base64URL alphabet turns it off, as JWTs expect. Tick it again if your system wants the
=. - Wrap lines at 76 characters is for MIME email bodies. Without it, the output is a single line.
- To read a token’s header and claims, use the JWT decoder, which decodes Base64URL with the same code.
- The Hash generator can show a digest in Base64 instead of hex, and compares Base64 checksums too.
Updated · Maintained by Liviu Tanase
Questions
Is my text or file uploaded?
No. Encoding and decoding run in your browser with JavaScript. A file is read from your disk by this page and never uploaded, and nothing you type is sent anywhere or put in the address bar.
What is the difference between Base64 and Base64URL?
Both turn every 3 bytes into 4 characters from a 64-character alphabet (RFC 4648). Standard Base64 uses + and / and pads the end with =. Base64URL uses - and _ instead, so the result is safe in URLs and file names, and usually drops the padding. JWTs use Base64URL without padding.
Is Base64 encryption?
No. It is an encoding: anyone can decode it, without a key. It makes binary data safe to carry as text, in email attachments, data: URIs and JSON. Don’t use it to hide passwords or tokens.
Why is the Base64 a third bigger than the input?
Every 3 bytes become 4 characters, so the result is about 33% larger, plus line breaks if you wrap at 76 characters as email does (MIME, RFC 2045). A 3 MB image becomes about 4 MB of text. Text is encoded as UTF-8 first, so é and € take 2 and 3 bytes.
Why does my Base64 decode to a file instead of text?
Base64 can hold any bytes. When the decoded bytes aren’t valid UTF-8, or contain control characters such as NUL, the page offers them as a download and names the file type it recognises from the first bytes, such as PNG, PDF or ZIP.
What counts as invalid input?
Any character outside A–Z, a–z, 0–9 and + / (or - _ for Base64URL), apart from = padding at the end. Spaces and line breaks are ignored. The error names the first bad character and its position, with the line and column when the text has several lines. A text that mixes + / with - _ is refused, because no encoder writes both.
How big a file can I encode?
Up to 100 MB, because the Base64 text is held in the page’s memory. For bigger files use the command line: base64 -i file on macOS, base64 file on Linux or certutil -encode file out.txt on Windows. Long results are shortened on screen, but Copy and Download take all of it.
How do I decode Base64 to an image or file?
Paste the Base64, or a whole data:image/png;base64,… URI, and choose Decode. When the bytes aren’t text, the page names the file type it recognizes from the first bytes (PNG, JPEG, GIF, WebP, PDF, ZIP, gzip and more), previews PNG, JPEG, GIF and WebP images, shows the first 256 bytes in hex and offers the file as a download.
How do I decode the Base64 in a JWT?
A JWT is three Base64URL parts joined by dots, usually without = padding. You can paste one part here, but the JWT decoder splits the token for you, decodes the header and claims with the same code and shows the times they hold. For a Base64 checksum of a file, use the hash generator.