Base64 Encoder and Decoder Guide: UTF-8, Base64url and Errors
ToolMellow ·
Base64 represents bytes using a small alphabet of printable characters. To encode text, ToolMellow first converts well-formed Unicode to UTF-8 bytes; to decode, it requires those bytes to form valid UTF-8 text. Paste your input, choose standard or URL-safe Base64, then press Encode or Decode. The conversion runs locally in your browser.
This guide explains the exact format this text tool accepts, useful examples and common errors. Base64 is reversible encoding, not encryption or compression. A successful conversion does not authenticate a token, make a password safe or prove that a file is harmless. Examples below are fixed illustrations, not measurements of your data.
How to encode or decode text
Open the Base64 encoder & decoder and paste text or an encoded string. Leave URL-safe Base64 off for the standard alphabet, or enable it when the receiving format requires Base64url. Encode converts the entire input to Base64; Decode converts it back to UTF-8 text. Typing alone does not run a conversion.
Read the result before using Copy result or Download. Use result as input replaces the editor with a result that fits the input limit; you can then choose the opposite action for a round trip. Editing input or changing conversion options invalidates the old result. Wrap lines changes display wrapping, not the encoded characters or inserted line breaks.
- Start with a known example such as
fooandZm9vbefore troubleshooting an application value. - Choose the alphabet required by your application; common letters and digits alone may not reveal which variant a string uses.
- Keep the original if byte-for-byte preservation matters. Text import, character encoding and extra line endings can change what you encode.
What Base64 does to bytes
Base64 divides each group of three bytes into four six-bit values, then maps those values to alphabet characters. A final short group needs special handling and may use padding. The visible letters are a representation of the input bytes; they are not a new language or a secret key.
These standard-alphabet examples include the empty string and one-, two- and three-byte ASCII endings. Spaces and line endings in the text you encode are real bytes and change the result. Decoding the same canonical encoding restores the original UTF-8 text, including those characters.
| UTF-8 text | Standard Base64 |
|---|---|
| Empty string | Empty string |
f | Zg== |
fo | Zm8= |
foo | Zm9v |
Hello | SGVsbG8= |
😀 | 8J+YgA== |
Standard Base64 versus Base64url
Both variants use letters and digits. Standard Base64 uses + and / for the final two alphabet symbols; Base64url uses - and _. ToolMellow emits trailing = in standard mode where needed, and omits it in URL-safe mode. For example, the emoji above becomes 8J-YgA in URL-safe mode.
The decoder accepts only the selected alphabet. Both modes accept unpadded input or correctly placed optional padding. Base64url itself does not universally ban padding: the surrounding protocol decides whether it is required, permitted or omitted. Select the required format rather than assuming every URL or token uses the same convention.
| Property | Standard mode | URL-safe mode |
|---|---|---|
| Final alphabet symbols | + and / | - and _ |
| ToolMellow encoding padding | Included when needed | Omitted |
| ToolMellow decoding padding | Correct padding or unpadded | Correct padding or unpadded |
| Mixed variant symbols | Rejected | Rejected |
Unicode, emoji and UTF-8 decoding
Text is converted through UTF-8, so accents, Chinese, Arabic and emoji can round-trip when the input is well-formed Unicode. JavaScript string length counts UTF-16 code units; UTF-8 byte length is different. The emoji 😀 occupies two UTF-16 units but four UTF-8 bytes, which produce eight padded Base64 characters.
Encoding rejects an unpaired Unicode surrogate. Decoding rejects invalid UTF-8 instead of silently replacing bad bytes. A leading encoded UTF-8 BOM is preserved as U+FEFF in the decoded string; it may be invisible in the editor. Valid text can also contain controls or different Unicode normalization forms. Base64 does not normalize text or make it safe to execute.
RFC 3629: UTF-8 character encodingWHATWG Encoding: TextEncoder, TextDecoder and BOM handlingECMAScript: String length and isWellFormed
Padding, whitespace and canonical unused bits
Padding is at most two trailing = characters, with the padded length divisible by four. The decoder also permits unpadded input with a valid ending, but a remaining length of one cannot represent a complete byte. Zg== and Zg both decode to f; Zg= is malformed. Empty input has a valid empty result.
Before decoding, ToolMellow removes only TAB, LF, CR and SPACE. It rejects form feed, vertical tab, nonbreaking space and other Unicode whitespace. The original input limit is checked before this removal. Its behavior is therefore narrower than a general promise to ignore all whitespace.
Unused bits in the final alphabet symbol must be zero in this tool. It checks that re-encoding the decoded bytes matches the normalized input without padding. Zh== is rejected although a lenient decoder might produce the same byte as canonical Zg==. RFC 4648 permits such stricter rejection; acceptance by another decoder does not prove canonical input.
RFC 4648: Base64, Base64url, padding and canonical encodingWHATWG Infra: Forgiving Base64 decodingWHATWG HTML: atob and btoa
How much larger is Base64, and what fits?
For n input bytes, padded Base64 length is 4 × ceil(n / 3) characters. Zero bytes produce zero characters; one byte produces four, two produce four and three produce four. The overhead approaches one third for large inputs, but it is not exactly 33% for every value. Unpadded URL-safe output removes the final one or two padding characters where applicable.
Count UTF-8 bytes for the size formula and UTF-16 code units for this editor limit. The tool permits up to 1,000,000 input code units before decoding whitespace is removed. It does not apply the same ceiling to output: one million ASCII bytes produce 1,333,336 padded characters. Copy and Download still work, but Use result as input cannot load a result over the input ceiling.
| Boundary | Actual limit or behavior |
|---|---|
| Editor / conversion input | Up to 1,000,000 UTF-16 code units |
| Local file byte size | Strictly below 4,000,000 bytes |
| Imported text length | Up to 1,000,000 UTF-16 code units |
| Encoded output | Can exceed the input ceiling; copy/download remain available |
RFC 4648: Base64, Base64url, padding and canonical encodingWHATWG Encoding: TextEncoder, TextDecoder and BOM handlingECMAScript: String length and isWellFormed
Opening a text file is not binary-file encoding
The file control reads a local file as UTF-8 text through File.text(). A file at or above 4,000,000 bytes is rejected; text longer than 1,000,000 UTF-16 units is also rejected after reading. The application does not upload the file to perform this conversion. A filename extension does not establish that its bytes are UTF-8 text.
Ordinary file-to-text reading removes a leading UTF-8 BOM and replaces malformed UTF-8 sequences. That can change the original bytes before encoding. It differs from the Base64 decoder, which rejects malformed UTF-8 and preserves decoded U+FEFF. For images, PDFs, arbitrary bytes or byte-exact file recovery, use the separate Base64 to file tool where appropriate; this text workspace is not a raw binary-file encoder.
W3C File API: Blob text readingWHATWG Encoding: TextEncoder, TextDecoder and BOM handling
Why is my Base64 invalid?
First identify the expected format and whether the value should decode to text. Remove surrounding application syntax deliberately, not by deleting unknown characters until it works. This decoder does not automatically extract data-URL payloads, token segments, quoted JSON strings or HTML. Those wrappers have their own parsing and validation rules.
If the alphabet and shape are valid but the decoded bytes are not UTF-8, the data may be a binary file or use another character encoding. That is a text-scope error rather than proof the Base64 bytes are corrupt. If clipboard access is unavailable, select the result and copy it manually. An unsupported browser or blocked worker can also prevent conversion; use a current supported browser and read the displayed error.
| Symptom | Likely reason | Useful next check |
|---|---|---|
A | Impossible final length | Confirm the entire value was copied |
Zg= | Incomplete padding | Use correct padded or unpadded input |
Zh== | Nonzero unused bits | Check the original producer; canonical form is Zg== |
8J-YgA in standard mode | Wrong alphabet selected | Use URL-safe mode if the protocol calls for it |
/w== | Decoded byte is invalid UTF-8 | Determine whether the payload is binary |
| Unexpected invisible character | BOM or control in decoded text | Inspect code points before reusing the result |
RFC 4648: Base64, Base64url, padding and canonical encodingRFC 3629: UTF-8 character encoding
Base64url, percent encoding and data URLs
Base64url and percent encoding solve different problems. Percent encoding represents selected URL bytes with % sequences; Base64url represents an entire byte sequence with its own alphabet. A plus sign becomes a space specifically in application/x-www-form-urlencoded parsing, not universally in every URL. Use the URL encoder & decoder for that separate task.
A data URL has a data: scheme, an optional media type and a comma before its payload, with a Base64 marker when applicable. Pasting the whole wrapper into this text decoder fails the alphabet check. Parse the intended payload using the appropriate tool and consider whether it is text or binary. Base64 does not make an embedded script, document or downloaded file trustworthy.
WHATWG URL: Form URL-encoded parsingRFC 2397: The data URL scheme
JWT segments and HTTP Basic are protocol data
Compact JWS uses three dot-separated segments; compact JWE uses five. Decoding a text segment of a JWT may reveal JSON, but it does not verify a signature, decrypt encrypted content, validate expiry or establish authorization. A signature segment can be arbitrary bytes and need not decode to UTF-8. Follow the actual token protocol and a maintained verification library in your application.
HTTP Basic credentials use a Base64 representation of a username/password sequence with protocol-specific character-encoding rules. Base64 adds no confidentiality. This UTF-8 text tool does not establish that a credential matches every server interpretation. Do not publish real credentials as examples, and use the required secure transport and authentication procedure.
RFC 7515: JSON Web Signature compact serializationRFC 7516: JSON Web Encryption compact serializationRFC 7617: HTTP Basic authentication
Base64 is not encryption, hashing or compression
Anyone who has a Base64 value can reverse the representation without a secret key. Encryption requires a cryptographic construction and key management; a hash produces a digest with different purposes and properties. Converting a password to Base64 is not suitable password storage. The separate hash tool produces digests, not a password-storage system or a substitute for encryption.
Base64 also expands bytes rather than compressing them. It can carry encrypted, compressed or signed bytes, but it does not create those protections itself. Decide what your application needs before adding an encoding layer, and keep secrets out of shared examples, screenshots and downloaded results.
Copy, download, round trips and clearing
Download saves the result as UTF-8 text in toolmellow-result.txt. This is neither a binary reconstruction nor a conversion report. A successful empty output still enables Copy result and Download. For a simple check, encode known text, use the result as input when it fits, then decode with the matching alphabet and compare the original text.
Clear removes input, result, errors, search/replacement content and editor history while retaining URL-safe and Wrap lines choices. Refreshing or closing the workspace discards its in-memory working data; files already downloaded remain on your device. Clear is not a guarantee of forensic erasure from browser or operating-system memory.
What local processing does and does not mean
The conversion runs in a browser worker. The application does not send pasted text, selected file contents or conversion results to a conversion server. Its working input is held in the current page rather than saved as an account history. Review the site privacy page for the full explanation of storage and temporary handoffs.
Loading the website still makes network requests. Hosting infrastructure receives ordinary connection/request metadata, and the public site uses Google Analytics for page visits with cookies and browser/device information. Local conversion is not anonymity or a promise of no network traffic or zero infrastructure logging. Downloaded files and a manually copied result can leave the workspace through your own actions.
Embed the Base64 tool with its backlink
Open the integration section below the tool workspace, choose the page language, and copy or download the supplied HTML snippet. Paste it into an HTML area that allows external iframes and scripts. The snippet includes the ToolMellow workspace iframe, its sizing script and a visible backlink to the matching localized ToolMellow tool page. Retain that credit link.
Preview the embed and check narrow screens. It keeps the same text scope and input limits; it is not a remote conversion API or a binary-file encoder. Clipboard access depends on browser permissions, and your platform must permit the external resources. The supplied backlink uses nofollow and noopener; its presence does not guarantee search ranking improvements.
Common questions
How do I encode text as Base64?
Paste well-formed Unicode text, choose standard or URL-safe mode, and press Encode. ToolMellow converts it to UTF-8 bytes and encodes those bytes locally. Copy or download the resulting text.
How do I decode Base64 to text?
Select the matching alphabet and press Decode. The tool validates format and canonical unused bits, then requires valid UTF-8. Correct optional padding and unpadded input are accepted; binary data may fail the text check.
What is the difference between Base64 and Base64url?
The last two alphabet symbols differ: standard uses + and /; URL-safe uses - and _. ToolMellow emits standard padding where needed and omits URL-safe padding. Both selected modes accept correctly padded or unpadded decoding input.
Why does Base64 end with equals signs?
One or two trailing equals signs fill the last four-character group when the byte count is not divisible by three. Padding is format-specific; this decoder permits a valid unpadded form too.
Does Base64 support emoji and non-Latin text?
Yes, through UTF-8. Emoji can occupy different numbers of UTF-16 units and UTF-8 bytes. Encoding rejects unpaired surrogates, and decoding rejects malformed UTF-8 rather than replacing it.
How much larger is Base64?
Padded length is 4 × ceil(input bytes / 3). The overhead approaches one third for large input and depends on rounding for short input. Measure UTF-8 bytes rather than displayed characters; unpadded URL-safe output removes final padding.
Why does another decoder accept a value ToolMellow rejects?
Decoders differ in accepted alphabets, whitespace, padding, unused pad bits and text character encodings. ToolMellow enforces its selected alphabet, four whitespace characters, zero unused bits and valid UTF-8. Lenient acceptance elsewhere is not proof of canonical input.
Can I decode a PDF or image here?
This tool outputs UTF-8 text, not arbitrary file bytes. Use the separate Base64 to file tool for appropriate binary reconstruction. The local file input here reads text and can remove a BOM or replace invalid UTF-8 before encoding.
Which whitespace can I include when decoding?
Only TAB, LF, CR and SPACE are removed. Form feed, vertical tab, NBSP and other Unicode whitespace are rejected. The original one-million UTF-16-unit input limit applies before whitespace removal.
Is Base64 encryption or safe password storage?
No. Base64 is reversible without a key and adds no confidentiality. It is not encryption, a password hash or compression. Decoding an authentication token also does not verify or authorize it.
Why can I download a result but not use it as input?
Encoded output can be longer than the one-million UTF-16-unit input ceiling. Copy and Download remain available, but Use result as input rejects an oversized result. One million ASCII bytes produce 1,333,336 padded characters.
Can I embed the tool on my website?
Yes. Use the localized HTML snippet below the workspace, retain its visible ToolMellow backlink, and check that your platform allows the iframe and sizing script. The embed uses the same text limits and is not a server conversion API.
Sources and further reading
- RFC 4648: Base64, Base64url, padding and canonical encoding
- RFC 3629: UTF-8 character encoding
- WHATWG Encoding: TextEncoder, TextDecoder and BOM handling
- ECMAScript: String length and isWellFormed
- WHATWG Infra: Forgiving Base64 decoding
- WHATWG HTML: atob and btoa
- W3C File API: Blob text reading
- WHATWG URL: Form URL-encoded parsing
- RFC 2397: The data URL scheme
- RFC 7515: JSON Web Signature compact serialization
- RFC 7516: JSON Web Encryption compact serialization
- RFC 7617: HTTP Basic authentication