Base64 Encoder and Decoder — Convert UTF-8 Text and Base64

Base64 Encoder and Decoder At a Glance

Base64 represents bytes using letters, digits, and a small set of symbols. It is commonly used when a format expects plain printable characters but the original input might contain bytes that are awkward to transmit directly. Encoding text changes its representation; it does not hide its meaning from anyone who can decode it. The output often contains a trailing equals sign because the original byte sequence does not divide evenly into groups of three.

This converter starts by representing text as UTF-8 bytes, then turns those bytes into standard Base64 or the URL-safe variation. For decoding, it first checks the alphabet and padding, converts the Base64 back into bytes, and requires the bytes to form valid UTF-8 text. Binary files are a different use case; a text-only decoder should not silently interpret arbitrary binary values as readable words.

How to Encode or Decode Base64

For an ordinary message, choose Encode UTF-8 text and paste the exact text you want to convert. Capital letters, punctuation, spaces, accented letters, and emoji are all allowed. Select URL-safe Base64 only when you need the alternative alphabet used by certain URL parameters and token formats. Press Convert Base64, inspect the output, then copy or save it as a text file. The tool does not insert line breaks into encoded results.

To decode, switch the operation to Decode UTF-8 text and paste the original Base64 string. Standard Base64 accepts its normal padding, and the decoder ignores ordinary spaces and line breaks in copied data. When URL-safe mode is selected, the decoder also accepts the dash and underscore substitutions and the unpadded form. If decoding fails, check whether the source is genuinely Base64, whether a character was lost, or whether the underlying content is binary rather than text.

What Base64 Encoding Actually Changes

Base64 takes three bytes at a time and represents them as four symbols. Each symbol encodes six bits, so four symbols hold the same twenty-four bits as three eight-bit bytes. A final group may require padding, shown as one or two equals signs. That relationship explains why the result is generally longer than the original bytes, even though it contains only an uncomplicated set of characters.

Suppose your input is the word hello. Its UTF-8 bytes are transformed into a Base64 value that can be decoded back into the same five letters. The process does not preserve an independent record of how the input was entered; line endings and invisible characters belong to the input itself and therefore affect the encoded value. Two visually similar strings may produce different Base64 outputs when their Unicode representations or whitespace differ.

UTF-8, Accented Letters, and Emoji

A common source of confusion is the relationship between characters and bytes. English letters usually use one UTF-8 byte, while many accented characters and most emoji occupy multiple bytes. Base64 operates on those bytes, not directly on the number of visible characters. If you compare Base64 values produced by different software, ensure both programs use the same text encoding before concluding that one result is incorrect.

This converter deliberately uses UTF-8 for both directions. During decoding it rejects byte sequences that cannot be interpreted as valid UTF-8, rather than replacing their contents with misleading placeholder characters. That decision is helpful when checking API payloads, JSON strings, or configuration values that should contain readable text. It also means a Base64-encoded photograph, ZIP file, or encrypted binary value will not be presented as if it were a valid document.

Standard Base64 Versus Base64url

Standard Base64 can contain the plus and forward-slash characters, along with equals-sign padding. Those characters have special meanings in some URLs, so the URL-safe variant replaces plus with dash and slash with underscore. In many systems it also omits padding. The underlying bytes are identical; the difference is the alphabet and output convention, not a different encryption method.

Choose the alphabet expected by the service consuming your value. A JSON Web Token commonly contains Base64url-encoded segments, but the token as a whole has a defined structure and may be signed. Decoding a segment can reveal its readable fields without demonstrating that it is authentic. Never treat successful decoding as proof that a token, claim, or message came from a trustworthy source.

Where Base64 Appears in Everyday Development

Developers encounter Base64 in email attachments, API requests, configuration records, data URIs, and systems that need binary-compatible content in text fields. It can be useful while checking whether text has survived a copy operation intact. A transparent example is a service that sends a small UTF-8 message as an encoded string; decoding lets you confirm the original punctuation and newlines without inventing additional content.

Base64 is not always the right representation. If you want to move structured information between applications, the JSON formatter and validator can reveal the hierarchy of keys and values without encoding the text itself. If a service expects a parameter in a link, URL encoding addresses reserved characters differently from Base64. Choosing the correct transformation prevents subtle compatibility errors.

How to Diagnose Invalid Base64

Invalid input can arise from a missing character, an unexpected symbol, incorrect padding, an extra copied quote mark, or confusion between standard and URL-safe alphabets. An error at the decoding stage is worth investigating instead of stripping characters until the text appears to work. Removing arbitrary symbols changes the underlying bytes and can conceal corruption from a truncated request or incorrectly assembled value.

Check the original data format first. A fragment copied from a JSON string may contain escaping that needs to be handled at the JSON level. A string pasted from a URL may have percent-encoded symbols or omitted Base64 padding. If the decoded bytes are not UTF-8, the content might be a binary payload or use a different character encoding. This tool makes that boundary explicit rather than displaying a mixture of replacement characters.

Security and Privacy Considerations

Base64 does not provide confidentiality. Anyone with a decoder can reverse it, so passwords, private API keys, access tokens, or personal records should not be considered protected just because they are encoded. Moving a secret into a visible text box also creates avoidable exposure through screenshots, screen sharing, clipboard history, and copied result files. Work with test values whenever possible.

The operation here uses a local text conversion routine and does not require an external decoding service. That describes this particular conversion, not a blanket promise about advertisements, analytics, or other site services. For sensitive production values, use your organization’s approved tools and avoid placing credentials into websites. Copying an encoded token into documentation is no safer than copying the underlying secret.

Checking a Round Trip Before Reusing the Value

When exchanging a value between systems, a useful quality check is to encode a short sample, decode it again, and compare the result character for character with the original. Pay attention to leading spaces, line endings, and characters outside the basic Latin alphabet. A successful round trip confirms the encoding and decoding rules agree for that sample, although it does not validate any separate authentication or business rules.

For extensive transformations, keep the original value available until the receiving application accepts the result. If you expect to inspect encoded content inside a structured record, start with a small representative payload and keep track of which layer performs each conversion. Base64, URL percent-encoding, and JSON escaping serve different purposes; applying one twice or reversing them in the wrong order is a frequent source of confusing output.

When to Preserve the Original Formatting

Encoded values are sometimes embedded in copied email headers, structured documents, or multi-line transport formats. Whitespace introduced for display may be ignored by one decoder and treated as an error by another. If you are comparing results across systems, document whether line breaks are part of the value or merely formatting added during transmission. The decoder on this page ignores ordinary whitespace in Base64 input, but a strict service might not, so use the exact output convention expected at the destination.

If a signature, checksum, or protocol expects exact bytes, a visually equivalent reserialization may still be wrong. Keep the raw original until you have verified the transformation. In particular, do not assume that a UTF-8 text decoder can preserve arbitrary binary content or that URL-safe alphabet substitutions resolve unrelated structural issues. Test with known text and its expected encoded result before handling values whose source or format is uncertain.

Frequently Asked Questions About Base64 Encoder and Decoder