Base64 Encoder & Decoder
Encode Unicode text to Base64 or decode UTF-8 Base64 text locally.
- Free
- No signup
- Runs in your browser
Text is encoded and decoded as UTF-8, including Unicode and emoji.
How it works
How to use
Choose Encode or Decode, enter text, and run the conversion.
Method
UTF-8 text is converted to or from standard Base64 locally.
Example
Encode Hello as SGVsbG8= and decode it again.
Base64 starts with bytes, not characters
Base64 is a way to represent bytes with a restricted set of text characters. For ordinary text, SnakTool first converts the characters to UTF-8 bytes and then encodes those bytes with the standard Base64 alphabet. Decoding reverses the route: Base64 characters become bytes, and those bytes must form valid UTF-8 before they can be shown as text.
That distinction matters whenever the input contains more than basic ASCII. The number of visible characters is not necessarily the number of encoded bytes, because a Unicode character can occupy multiple UTF-8 bytes.
Text: Hello
UTF-8 bytes (hex): 48 65 6c 6c 6f
Base64: SGVsbG8=Three bytes become four Base64 characters
Base64 processes binary data in 24-bit groups. Three 8-bit bytes make 24 bits, which are divided into four 6-bit values. Each 6-bit value selects one symbol from a 64-character alphabet.
For example, the three ASCII bytes for Man form one complete 24-bit group and encode as TWFu. This 3-to-4 relationship also explains why Base64 representation normally takes more space than the original bytes.
Text: Man
Bytes: 77 97 110
3 bytes = 24 bits
4 groups × 6 bits
Base64: TWFuThe equals sign is padding, not hidden information
The final input group is not always three bytes long. Standard Base64 can use = characters to fill the last four-character group when only one or two source bytes remain. One source byte needs two padding characters; two source bytes need one.
That is why M becomes TQ== while Ma becomes TWE=. An input whose byte length divides evenly into groups of three, such as Man, needs no padding and becomes TWFu. The padding describes the shape of the final encoded group; it is not encryption or extra source data.
UTF-8 carries Arabic, accents, and emoji through the round trip
Base64 itself has no concept of Arabic letters, accented characters or emoji. It only sees their encoded bytes. SnakTool uses UTF-8 for the text-to-bytes step, so multilingual text can be encoded and recovered without pretending that every character fits in one byte.
On decode, the tool uses strict UTF-8 handling. If a syntactically valid Base64 value represents arbitrary binary bytes rather than valid UTF-8 text, SnakTool rejects the text conversion instead of silently replacing invalid byte sequences with placeholder characters.
Valid Base64 does not guarantee readable text
Base64 can represent any bytes, including image, PDF, archive and other binary file data. A Base64 string can therefore be structurally valid even when decoding it does not produce readable text.
This page is a text encoder and decoder: its decode path expects the resulting bytes to be valid UTF-8. It is not a general binary-file decoder. If the payload represents an image or another file format, use a workflow designed for that binary data rather than treating the bytes as text.
Base64 adds size instead of compressing data
For each complete three-byte input group, Base64 writes four characters. Ignoring padding and surrounding transport overhead, that makes the encoded representation about one third larger than the original byte sequence.
This tradeoff is useful when binary bytes need to travel through a text-oriented format, but Base64 is not compression. Encoding a large payload does not make it smaller, and wrapping Base64 inside JSON or another text format can add further characters around it.
Standard Base64 and Base64URL use different symbols
Standard Base64 uses letters, digits, + and /. URL-safe Base64 variants replace the two punctuation characters with - and _ so those values fit more conveniently into URL-oriented contexts.
SnakTool's Base64 Encoder & Decoder expects the standard alphabet. A token containing - or _ belongs to the URL-safe variant and is not accepted here as standard Base64. JWT segments, for example, use Base64URL rather than ordinary Base64.
A data URL contains more than the Base64 payload
A value such as data:image/png;base64,iVBORw0... contains metadata before the encoded bytes. The data:image/png;base64, prefix identifies the media type and encoding; it is not part of the Base64 payload itself.
This text decoder expects the Base64 value rather than a data URL wrapper. It also cannot turn image bytes into UTF-8 text. When the goal is to work with image data, keep the distinction between the data URL metadata, its Base64 payload and the binary image bytes.
Encoding is reversible, so it is not secrecy
Base64 has no password, key or confidentiality property. Anyone who receives an encoded text value can decode it. The unfamiliar-looking output is a transport representation, not protection for passwords, API secrets or private messages.
Encryption addresses confidentiality with cryptographic keys, while hashing produces a digest for a different purpose. Base64 does neither. Use it when a system needs bytes represented as text, not when the requirement is to keep the underlying value secret.
Frequently asked questions about Base64 Encoder & Decoder
Why is valid Base64 rejected as UTF-8?
The decoded bytes may represent binary data or another text encoding rather than valid UTF-8. This text decoder deliberately rejects invalid UTF-8 instead of replacing bytes silently.
Does whitespace make Base64 invalid here?
No. The decoder removes whitespace before validating and decoding the standard Base64 payload, so line breaks and spacing can be tolerated.
What is Base64 encoding?
Base64 represents bytes using a 64-symbol text alphabet. For text input, SnakTool first encodes the characters as UTF-8 bytes and then converts those bytes to standard Base64.
Is Base64 encryption?
No. Base64 is reversible encoding and uses no secret key. Anyone with the encoded value can decode it, so it should not be used to protect passwords, tokens or confidential messages.
Why is Base64 about 33% larger than the original data?
Each complete group of three source bytes is represented by four Base64 characters. Four units for every three source bytes creates roughly one-third encoding overhead before any surrounding format overhead.
Can this Base64 decoder decode files?
No. The current Base64 Encoder & Decoder is text-oriented. A valid Base64 file payload can be rejected when its decoded bytes are not valid UTF-8 text.
Should I paste the data:image/...;base64, prefix?
No. A data URL prefix is metadata outside the Base64 payload. This decoder expects the encoded payload itself, and image bytes are not generally UTF-8 text.
What is the maximum input size for this Base64 tool?
The current developer-text limit is 1,048,576 UTF-16 code units. Input above that limit is rejected before encoding or decoding.