If ordinary English text converts correctly but an accented word or emoji breaks your Base64 workflow, check the text-to-bytes step. Base64 encodes bytes. For text, both sides need to agree on a character encoding such as UTF-8 before the result can be read reliably.
This guide uses the Base64 Encoder and Decoder to test that round trip, choose the right output variant and diagnose common decoding failures.
Base64 does not make information secret
Base64 is a reversible representation of data. Someone who has the encoded value can decode it without a secret key. Do not treat an unfamiliar-looking output string as a protected password, private document or encrypted message.
RFC 4648 defines the encoding, including its alphabet and padding rules. Three input bytes normally become four output characters; a final incomplete group is padded in the standard form. For standard padded output, the length is:
4 × ceil(number of input bytes ÷ 3)Count bytes, not just visible letters. Two strings with the same number of visible characters can have different UTF-8 byte lengths. For example, a short non-ASCII label can need more bytes than an equally short label made from basic Latin letters.
Run an accented-text and emoji round trip
Use this non-sensitive sample, including the space between the word and symbol:
Café ☕- Open the tool and choose Encode text to Base64.
- Paste the sample into Input, with no extra leading or trailing newline.
- Leave URL-safe alphabet and Wrap output at 76 characters unchecked for this first test.
- Select Convert. The output should be
Q2Fmw6kg4piV. - Select Use output as input. The tool switches to decoding and should restore the same sample.
The tested sample uses nine UTF-8 bytes and produces twelve Base64 characters. Its byte count is divisible by three, so this output has no trailing equals signs. Absence of padding does not automatically mean a string is incomplete.
When checking your own text, include a representative accented character or symbol if your application accepts them. A test using only hello cannot reveal every text-encoding mismatch.
Why direct btoa calls can fail
The browser’s btoa() function expects a string representing bytes, not arbitrary Unicode text. A character outside its single-byte range can trigger an error. Convert text to UTF-8 bytes first, then Base64-encode those bytes. Decode in the reverse order.
MDN’s btoa documentation explains this distinction and the TextEncoder/TextDecoder approach. The site’s tool uses that approach in browsers with those APIs. Its successful round trip checks the sample conversion; it does not prove that another application expects UTF-8 or the same Base64 variant.
Choose standard or URL-safe output deliberately
Standard Base64 can contain + and /. The URL-safe alphabet replaces those with - and _. Whether padding is included depends on the receiving format’s rules. Do not switch variants merely because one output looks shorter.
In this tool, selecting URL-safe alphabet also removes trailing padding. The decoder accepts the URL-safe symbols and can restore omitted padding when the remaining length permits it. This is useful for testing, but acceptance by this decoder does not guarantee acceptance by a stricter API.
Wrapping output at 76 characters is a separate setting. Leave it off for a single-line API field unless the destination explicitly requires wrapped data. When decoding pasted multiline input, the tool’s Strip whitespace before decoding option can remove that whitespace.
Troubleshoot the symptom you actually see
The decoder reports invalid input
Check for copied quotation marks, a missing character, a prefix such as data:image/png;base64,, or an equals sign in the middle. Paste only the encoded payload into this text decoder. For a padded example, OK encodes as T0s=; the equals sign belongs at the end.
The output is readable but wrong
Compare the original input, including spaces and line endings. Then ask how the source produced its bytes. A Latin-1 byte sequence and a UTF-8 byte sequence can represent similar-looking text but are not interchangeable. Do not repeatedly encode a broken result in the hope that it will repair the original.
The decoded output contains replacement characters or gibberish
The payload may be binary data or text in another encoding. This tool presents decoded bytes as UTF-8 text; it is not a general binary-file recovery tool. A successful Base64 parse alone does not identify the original file type or prove the text was decoded losslessly.
A value changes after being placed in a query string
A literal plus sign can be interpreted as a space during query parsing. MDN’s URLSearchParams documentation illustrates this issue. Use a URL-aware serializer for the query value, or use Base64url if the receiving protocol requires it. Do not make ad hoc replacements without checking that protocol.
Validate the content after decoding
Decoding answers how the bytes were represented, not whether their contents are valid for your application. If the decoded value is supposed to be JSON, check it with the JSON Formatter and Validator. Our invalid-JSON repair examples explain the next checks for quotes, commas and brackets.
Keep a known input and expected output with your integration notes. A short round-trip test with realistic characters is easier to diagnose than a long opaque value copied from a failing application.