Base64 Encoder and Decoder (All Browser Support)

Base64 Encoder and Decoder

What Base64 encoding is

Base64 turns bytes into a text string made from 64 printable characters. It is used when a system can carry text but not raw binary: email attachments, JSON fields, data URIs, tokens and configuration files. The output is longer than the input, usually by about a third. Base64 is not encryption and it is not compression. Anyone can decode it. It hides nothing and shrinks nothing; it simply makes binary data safe to move through text-only channels.

Encoding text in the browser

Open the Encode tab, type or paste text into the editor and wait for the automatic conversion. You can also press the encode button. The result appears in the output area, with character counts and a blow-up percentage. The conversion uses the browser's text encoder and btoa, so it handles ordinary Unicode text after encoding it to bytes. Copy the result into the destination field. Nothing is uploaded; the text stays in the page.

Decoding Base64 text

Open the Decode tab, paste a Base64 string and let the tool decode it. A data URI prefix such as data:image/png;base64, is stripped before decoding. If the string is valid, the plain text appears in the output. If it is not valid, the page shows an error instead of silently producing garbage. Use the clear button before starting a new value, especially if you are comparing several strings.

Data URIs and prefixes

A data URI combines a media type, an optional base64 marker and the encoded bytes in one string. For example, a small PNG can be written as data:image/png;base64, followed by the Base64 payload. This tool removes that prefix when decoding, so you can paste the whole URI or just the payload. It does not validate that the declared media type matches the bytes. A prefix is a label, not proof of the file's contents.

Character counts and size growth

The page shows input and output character counts and a blow-up percentage. Base64 normally produces about four characters for every three bytes, which is roughly a 33 percent increase before any line breaks or prefixes. A long document can therefore become a much larger string. If a field has a size limit, check the encoded length, not the original word count. The tool does not provide a line-wrapping option or a URL-safe alphabet.

File upload and binary data

Use the file upload control on the Encode tab to encode a file directly. The page reads the file bytes once and writes the Base64 straight into the output, while the input editor shows a short summary with the file name, type and size. This is the path to use for images, PDFs, ZIP files and other binary data. When you decode, the page checks the first bytes of the result for PNG, JPEG, GIF and WebP signatures, shows the detected type and byte count, and previews the image using that type.

Encoding versus encryption

Base64 is sometimes mistaken for protection because the output looks unreadable. It is trivially reversible. If you need confidentiality, use encryption and key management. If you need integrity, use a signature or a checksum. If you need to store a password, use a password-hashing function, not Base64. Never put a secret into a Base64 string and assume it is safe because it no longer looks like plain text.

When Base64 is useful

It is useful for embedding a small image in CSS or HTML, sending binary data through a JSON API, storing a small certificate or key fragment in a text field, and debugging an email attachment. It is a transport encoding. Use it at the boundary where a text-only channel requires it, then decode it back to bytes at the other end. Do not use it as a database storage strategy for large files when a file store is available.

URL-safe and line breaks

Standard Base64 uses plus and slash, which can be awkward in URLs. A URL-safe variant replaces them with hyphen and underscore. This tool does not expose a URL-safe mode, and it does not add or remove line breaks. If an API expects URL-safe Base64, use a converter that supports that alphabet. If it expects MIME line wrapping, check the specification; a single long line may be rejected.

Privacy and local processing

Encoding and decoding happen in your browser. The text is not sent to Newisty. That makes the page convenient for non-sensitive payloads, but local processing does not make a secret safe. The browser, extensions, clipboard and screen recording can still expose the value. Clear the editor when you are done, avoid pasting production credentials, and remember that copied text may remain in the clipboard history.

Common problems

If decoding fails, check for spaces, line breaks, a missing padding character or a prefix that was not removed. If the output looks like mojibake, the bytes may not be UTF-8 text. If the page is slow with a very large value, the browser is holding the whole string in memory; there is no streaming mode.

What not to do

Do not call Base64 encryption. Do not use it to hide passwords, API keys or personal data. Do not paste a production secret into a random online tool. Do not assume the decoded bytes are an image just because the string starts with a known prefix. Always verify the decoded output before using it.

Worked examples and padding

Base64 works on groups of three bytes, turning each group into four characters. When the input does not divide evenly into threes, the output is padded with one or two = signs. That is why short strings show a much larger Blowup figure than the usual third:

The last row shows why non-English text grows more: the Blowup compares characters, but an accented letter takes two bytes in UTF-8, and emoji take four. If a field limit is measured in characters, measure the encoded output, not the original text.

Loading Base64 from a file and the Type label

On the Decode tab, Upload .txt reads a .txt, .b64 or .base64 file as text, puts its contents in the input editor and decodes it straight away. The file is read by your browser and is not uploaded. Below the decoded output, the Type label reads "text" unless the decoded bytes start with the file signature of a PNG, JPEG, GIF or WebP image. In that case the label shows the image type, the output box shows a summary such as [image/png, 2,048 bytes] instead of unreadable characters, and the preview uses the detected type. Ordinary text, even text beginning with "GI" or "RI", stays labelled as text.

Frequently Asked Questions