Base64 Encoder / Decoder

Convert text to and from Base64. The conversion runs in your browser and the script makes no network request with your input.

What Base64 is and when people use it

Base64 is a way of writing any sequence of bytes using only 64 printable characters: the 26 uppercase letters, the 26 lowercase letters, the 10 digits, plus + and /, with = used at the end for padding. It exists because many channels were built for text, not for raw bytes. Email bodies, JSON fields, HTTP headers, HTML data: URIs and configuration files can all carry plain characters safely, but an arbitrary byte such as 0x00 or 0xFF might be altered, rejected or misread along the way. Encoding the bytes as Base64 lets them pass through intact. You will meet it in the HTTP Basic authentication header (Authorization: Basic ...), in each segment of a JSON Web Token (which uses the URL-safe variant), in email attachments and in small images embedded directly in CSS. This page turns your text into UTF-8 bytes and encodes those, and in the other direction decodes Base64 into bytes and reads them as UTF-8 text.

How it works: three bytes become four characters

Three bytes are 24 bits. Split those 24 bits into four groups of six, and each group is a number from 0 to 63. That number is then looked up in a 64-character alphabet (A to Z are 0 to 25, a to z are 26 to 51, 0 to 9 are 52 to 61,+ is 62 and / is 63). As an example, Man is the bytes 77, 97 and 110. Written in binary and joined, they read 010011 010110 000101 101110, which is 19, 22, 5 and 46, and those map to the four characters TWFu.

When the input is not a multiple of three bytes, the encoder pads the output so it always ends on a group of four. One leftover byte becomes two characters followed by ==, and two leftover bytes become three characters followed by =. The consequence is that the output length is always 4 × ⌈bytes ÷ 3⌉, so Base64 text is about one third larger than the data it represents.

Test vectors (calculated at build time)

These rows were produced by encoding the UTF-8 bytes of each input when the page was built, so you can compare them with the tool above, or with your own code, to confirm an implementation is correct.

InputCharactersUTF-8 bytesBase64
(empty string)00(empty)
a11YQ==
ab22YWI=
abc33YWJj
Hello, World!1313SGVsbG8sIFdvcmxkIQ==
{"id":1}88eyJpZCI6MX0=
café45Y2Fmw6k=
😀148J+YgA==
user:pass99dXNlcjpwYXNz

The table shows why character count and byte count are different things. A plain English letter is one byte, the accented é in "café" takes two, and the emoji takes four. Text in languages such as Japanese, Chinese or Korean uses three bytes per character in UTF-8, which is why the same number of characters makes a longer Base64 string. An empty input produces an empty output, which is not an error.

How much bigger does the data get?

Original bytesBase64 charactersPadding (=)Compared with original
142400.0%
241200.0%
340133.3%
10162160.0%
1001362136.0%
1,0001,3362133.6%
1,048,5761,398,1042133.3%

A 1 MiB file (1,048,576 bytes) becomes about 1.33 MiB of text. Embedding an image directly in HTML or CSS saves one network request but enlarges the document and prevents the image from being cached separately, so it is best kept for small items such as tiny icons.

The URL-safe variant

In a URL, + can be read as a space and / as a path separator, so standard Base64 can break when placed in a query string or a file name. The URL-safe alphabet (called base64url in RFC 4648) uses -in place of + and _ in place of /, and padding is often dropped. For example, the text subject?>> encodes to c3ViamVjdD8+Pg== in the standard alphabet andc3ViamVjdD8-Pg in the URL-safe one. Tick the checkbox before encoding to get this form. When decoding, this tool accepts either alphabet regardless of the checkbox.

Three things to try

1. Check an authentication header. Encoding user:pass gives dXNlcjpwYXNz. If you seeAuthorization: Basic dXNlcjpwYXNz in a request, anyone who sees it can decode the username and password in a second, which is why Basic authentication must only be used over HTTPS.

2. Round-trip some accented text. Encode café and you get Y2Fmw6k=. Paste that back in and press the decode button to recover the original. The byte count in the status line explains the padding: five bytes is not a multiple of three, so one = is added.

3. Paste messy input. If a value has line breaks or spaces in it, uses - and _, or has lost its padding, the decoder cleans it up before reading it. Base64 wrapped every 76 characters, the way email systems write it, can be pasted as is.

Edge cases and limits

Non-ASCII text. The tool converts text to UTF-8 bytes first. If another tool or programming language gives a different result for the same accented or CJK text, it probably used another character encoding such as UTF-16 or a legacy code page. Decoding here only interprets bytes as UTF-8, so bytes from a different encoding produce a message that the result is not UTF-8 text.

Binary data. Decoding an image, a PDF or encrypted bytes does not produce readable text, so the tool reports an error. It is a text tool, not a file converter.

Invalid input. A character outside the Base64 alphabet, or a length that leaves a single stray character after removing padding (which cannot represent a whole byte), is reported as invalid.

Large input. Text of a few hundred kilobytes is normally handled instantly. Very large inputs can make the tab pause for a moment; the conversion works in chunks so it does not hit argument-length limits.

Privacy and security

The conversion script reads the text box and processes it in the page. It does not send your input anywhere and does not store it. Other parts of the site, such as ad scripts, run separately, so for live passwords or API keys it is wiser to use a local tool. Above all, remember that Base64 is not encryption. Anyone can reverse it without a key, so "I Base64-encoded it" is never a reason to consider a secret protected. If you need protection, use real encryption, and if you need a one-way fingerprint, use a hash.

Where the result is useful

Typical uses are inspecting authentication headers, reading the payload of a JWT (decode one segment with the URL-safe option and you will see JSON), checking values inside configuration files, and producing test data. If the decoded text is JSON, the JSON Formatter will indent it for you.

Frequently Asked Questions

Is Base64 encryption?

No. Base64 is an encoding that anyone can reverse without a key. Never use it to protect passwords or sensitive information.

My accented or non-English text comes out garbled.

This tool uses UTF-8, so such text is encoded and decoded correctly. If a string produced elsewhere looks wrong, the source may have used another encoding, or the data may be binary and not text.

Why is there an = at the end, and can I remove it?

It is padding that keeps the output in groups of four characters when the input is not a multiple of three bytes. URL-safe variants often leave it out, and this decoder can restore it, but some strict libraries refuse input without padding.

A value containing + or / breaks in my URL.

In a query string, + can be read as a space and / as a path separator. Use the URL-safe option when encoding, or percent-encode the value with the URL Encoder.

How is Base64 different from a hash?

Base64 is reversible and its length grows with the input. A hash is a one-way, fixed-length fingerprint. For hashes, use the Hash Generator.

Related tools