An API example contains an encoded field, but decoding it produces unreadable characters. Before changing the request, separate three questions: is the input complete, is it the expected Base64 variant, and are the decoded bytes actually text?
The BiNotePads Base64 Encoder / Decoder is a text utility. It is useful for a small, invented development sample. It is not a general file decoder, an authentication-token inspector or a way to conceal a password.
Use a word that exercises UTF-8
The word hello is a convenient first test, but an accented word can expose a text-encoding mismatch that an ASCII-only sample misses. In Encode mode, enter this exact text with no quotation marks or extra newline:
caféSelect Process. The expected output is:
Y2Fmw6k=Switch Mode to Decode, paste Y2Fmw6k= into Input and process it. The output should be café again. Both directions were checked in the live tool on October 15, 2026.
Keep the example unchanged while diagnosing a problem. Adding a newline or replacing the accented letter changes the underlying bytes, so a different encoded value is not automatically an error. Two strings can also look similar while containing different Unicode sequences; this short example is a practical check, not a complete Unicode normalization test.
Understand what the result proves
A successful round trip shows that this input survived this pair of conversions. It does not prove that a remote service expects the same representation or that a supplied value is safe to use.
MDN's Base64 reference describes Base64 as a representation of binary data using a restricted text alphabet. Text must first have a byte encoding, such as UTF-8. That is why a decoder can return bytes that do not form a readable document: the original content may have been an image, compressed data or another binary format.
If an API field is documented as a file, use the application's file-handling workflow rather than trying to read the decoded bytes as prose. If it is documented as UTF-8 text, compare a harmless sample from the documentation before trying a larger payload.
Check the alphabet and the surrounding wrapper
Standard Base64 uses + and /, and may end with = padding. URL-safe Base64 uses - and _ in place of those two characters; padding conventions depend on the format. The distinction is specified in RFC 4648, sections 4 and 5.
Do not assume every encoded-looking value can be pasted into the same decoder unchanged. A data URL can include a media-type prefix. A structured token can contain several separate sections. An API response may wrap the field in JSON quotation marks. Read the field's format description before removing characters or changing the alphabet.
If the value came from a tutorial, use the tutorial's public sample. Do not paste a live account token merely because its format resembles Base64. Encoding provides no secrecy: someone who receives the encoded text can reverse the representation without a password.
Diagnose a mismatch one step at a time
First, repeat the café test to establish that the chosen mode and copy operation work. Next, compare the API's declared format with the characters in the sample. Then check for missing characters, copied quotation marks and line wrapping. Keep an untouched copy instead of repeatedly editing the only version.
When decoding succeeds but the result looks wrong, return to the byte encoding and content-type questions. When a round trip succeeds locally but a server rejects it, inspect the server's field requirements: it may expect a different variant, an entire file or a particular wrapper. Re-encoding the same text repeatedly does not resolve a format disagreement.
For JSON request bodies, check the enclosing structure separately with the JSON Formatter & Validator. Valid JSON and correctly represented text are independent checks; neither confirms that the API will accept the request.
Build a minimal bug report without sharing a secret
When reporting an encoding problem, give the receiving developer a tiny reproducible example instead of the original account data. Include the declared character encoding, Base64 variant, exact sample input and expected decoded text. The accented-word example in this guide is enough to distinguish an ordinary ASCII check from a UTF-8 check.
Record whether a newline is part of the source. “The text is café” leaves that unclear; “four visible letters, no trailing newline, UTF-8 bytes” is a more useful instruction. If the system expects a JSON field containing the encoded value, show the field with the public sample and make clear that it is a development fixture.
Include what actually failed. A decoder error, unreadable decoded characters and an HTTP rejection are different observations. For example, “The local round trip returns café, but the test endpoint rejects the field” points attention toward the request contract instead of the text conversion alone.
Do not repair the report by decoding and re-encoding an unknown production token. That can change padding or representation while leaving the real issue unexplained. Return to the service's format documentation and reproduce the failure with harmless data first.
Keep the smallest passing example beside the smallest failing example. Their differences are often easier to inspect than a long payload copied from an application log.