Base64 Encoder / Decoder

Base64 text conversion: what this browser tool handles

Base64 is a text-safe representation that becomes familiar once you start noticing it in API requests, email bodies, data URLs, authorization headers, JSON payloads, configuration files, and debugging logs. It is neither encryption nor compression. Base64 simply represents bytes with a restricted alphabet of printable characters, allowing data to pass through systems that are designed to handle text.

This Base64 encoder and decoder works in both directions. Paste ordinary text and choose Encode to create a Base64 value, or paste a Base64 value and choose Decode to inspect its text content. You can also load a local text file into the input area. That is useful when checking an API payload, verifying an encoded configuration value, or copying a converted result into another developer tool without writing a script.

Because this Base64 conversion runs locally in JavaScript, pasted text remains in the browser page while it is processed. The direct input-and-result layout is intended for quick inspection, teaching, and one-off text conversions where seeing the source and converted value side by side is more useful than remembering command-line syntax.

Using the Base64 encode, decode, copy, and download controls

This Base64 form uses one input area for both encoding and decoding, plus an optional local text-file picker and a result area. The action button determines whether the current input is treated as ordinary text or as Base64.

  1. Paste text into “Text to encode or decode” to work directly with copied or typed content. For encoding, enter readable text; for decoding, enter a Base64 string.
  2. Or choose a local file to read a text file into the Base64 input box. This suits text snippets, configuration files, source files, logs, and saved payloads.
  3. Click Encode to convert the current text to Base64. Click Decode to convert standard Base64 back to text. Click Clear to reset the input, result, selected file, and error message.
  4. Use the result box as copy-ready output. Copy result sends the displayed result to the clipboard when the browser permits it. Download decoded saves the current result as a plain text file named decoded.txt.

There is no separate Base64 mode selector: the button is the mode. The same text area can therefore contain plain text before encoding or Base64 before decoding, so check which action you are about to run before replacing the result.

Base64 input rules, text-file handling, and decoding errors

For Base64 encoding, the page accepts normal text and uses browser Unicode handling so many non-ASCII characters can be represented safely. For Base64 decoding, the value must be valid standard Base64. Leading and trailing whitespace is removed before decoding, which helps with copied payloads, but misplaced characters within the string can still produce an error. A failed decode commonly means that the value is not Base64, copied punctuation or whitespace altered it, or the source uses URL-safe Base64 characters instead of the standard alphabet.

The Base64 file option deliberately reads the selected file as text. It is appropriate for local JSON, logs, templates, source code, notes, and similar readable files. It is not a binary-file encoder with guaranteed binary round-trip behavior: an arbitrary binary file may be interpreted as text before the conversion begins. Likewise, the download control saves the current result as text.

That text-focused scope makes the tool practical for common debugging and documentation tasks without suggesting that it is a replacement for a binary-aware pipeline. When byte-for-byte handling of binary assets, streaming data, or a nonstandard Base64 variant is required, use a utility designed for that purpose.

How standard Base64 reorganizes bytes into characters

Standard Base64 reorganizes bits; it does not create new information. Three input bytes contain 24 bits. Base64 divides those 24 bits into four 6-bit groups, assigns every group a value from 0 through 63, and maps that value to a character in its alphabet. The familiar alphabet uses A-Z, a-z, 0-9, +, and /. Since three bytes normally become four characters, encoded Base64 is roughly one-third larger than the original bytes before line wrapping or other protocol overhead.

For Base64 text, the useful size relationship is based on bytes rather than visible characters. If UTF-8 input contains n bytes, its standard Base64 output length C is four times the ceiling of n divided by three. The number of trailing padding characters p is determined by the remainder after division by three.

C = 4 · n 3 p = ( 3 - ( n  mod  3 ) )  mod  3

In a Base64 value, a byte count divisible by 3 produces no padding. A final remainder of one byte produces ==, while a final remainder of two bytes produces =. These endings are a useful visual clue when you are checking whether an encoded value has been truncated or copied incorrectly, although padding alone does not prove that the entire value is valid.

The decoder reverses that representation for valid standard Base64 text: it maps Base64 characters back to their 6-bit values, reassembles bytes, and returns the decoded text. This page trims only the outside whitespace before that operation, so retain the original characters and padding when validating a payload.

Base64 example: encoding and decoding the word Hello

Take the text Hello. It contains 5 bytes in standard UTF-8 because each of those letters uses one byte. Divide 5 by 3 and you get 1 full chunk with a remainder of 2. That means the Base64 result will use 4·53=8 characters in total, and it will need exactly one padding character because the remainder is 2.

If you paste Hello into the input box and click Encode, the result is SGVsbG8=. That trailing equals sign is not decoration. It signals that the final Base64 quartet came from a short final chunk. If you then paste SGVsbG8= back into the same input box and click Decode, the result returns to Hello. That two-way check is a useful verification step when a Base64 payload may have been copied incorrectly.

This Base64 reference table shows the recurring relationship between input-byte count, output length, and final padding. The pattern repeats for every group of three bytes.

Input bytes Encoded characters Padding Example pattern
1 4 == One byte becomes two meaningful Base64 characters plus two pad characters.
2 4 = Two bytes become three meaningful Base64 characters plus one pad character.
3 4 None A full 24-bit chunk becomes four Base64 characters exactly.
4 8 == on the final quartet Three bytes fill one quartet, and the remaining single byte creates a padded quartet.
5 8 = on the final quartet Three bytes fill one quartet, and the remaining two bytes create a singly padded quartet.
6 8 None Two complete 24-bit chunks produce eight characters with no padding.

Reading Base64 encoding and decoding results safely

The result from this Base64 tool is text, and that distinction prevents two frequent misunderstandings. First, Base64 output is not encrypted: anyone who has the value can decode it. Do not treat Base64 encoding as protection for passwords, tokens, or other secrets. Second, decoded text is meaningful only in the context of its source. A value may decode to JSON, compressed data represented as text, another encoded layer, or content that needs additional interpretation.

After a Base64 conversion, compare the result with what you expected. Encoded plain text normally appears as a dense sequence of letters, digits, plus signs, slashes, and perhaps trailing equals signs. A successful decode may reveal readable prose or structured text such as JSON or XML. Replacement characters, unreadable output, or an error can indicate that the source was not valid Base64 text, was encoded with a different character convention, or was not intended to be interpreted as text.

Base64 also has a size cost. It is useful when a text-safe representation is necessary, but it is less compact than raw bytes. For storage and network planning, allow for approximately a 33% increase in size before other formatting or transport overhead.

Limits of this browser-based Base64 text converter

This Base64 page is intentionally lightweight and assumes text-oriented work. Its decoder expects standard Base64 characters and can reject malformed input. Some systems use URL-safe Base64, replacing + and / with - and _; normalize that variant before using this decoder if necessary. Very large pasted values can also be slow because the whole value is processed in the browser at once.

Within those limits, the Base64 encoder and decoder is well suited to private, everyday text conversion and debugging. Use it to inspect a payload, verify a generated Base64 string, test a short message, or explain padding behavior. Choose a specialized binary-oriented utility when the task requires exact binary fidelity, streaming, or variant-specific handling beyond standard text conversion.

Paste normal text to create Base64, or paste a Base64 string to recover the original text. During decoding, leading and trailing whitespace is ignored.

The selected file stays on your device. This page reads the file as text, so it is best for plain-text files such as JSON, logs, source code, or notes.

The converted text appears here. Use Copy result to copy it, or Download decoded to save the current output as a plain text file named decoded.txt.

 
Enter text or load a local text file to encode or decode Base64. Nothing is uploaded by this page.
Ready to report copy status.

Base64 padding mini-game: Padding Panic

This optional Base64 padding game turns the final-chunk rule into a quick recognition exercise. Each packet displays a byte count. When it reaches the glowing gate, send it to No = when the count is divisible by 3, One = when the remainder is 2, or Two == when the remainder is 1. Click or tap a lane on the canvas, or press 1, 2, or 3. The increasing pace helps reinforce how the last Base64 chunk determines padding.

Score: 0 Time: 75s Streak: 0 Best: 0 Phase: Warm-up

Padding Panic

Sort packet sizes by the padding Base64 will need on the last quartet. Build a streak for bonus points and survive the full 75-second run.

  • Lane 1: No padding when bytes mod 3 = 0.
  • Lane 2: One = when bytes mod 3 = 2.
  • Lane 3: Two == when bytes mod 3 = 1.
  • Click or tap the lane as a packet crosses the bright gate, or use keys 1, 2, and 3.

Educational takeaway: Base64 always works in 3-byte input chunks that become 4 output characters, so the final remainder determines whether you see no padding, one equals sign, or two.

Embed this calculator

Copy and paste the HTML below to add the Base64 Text Encoder and Decoder – Browser-Based UTF-8 Converter to your website.