payload.b64 — 2 tools ● LIVE
Input · raw 0 CHARS
NETWORK PAYLOAD: 0 BYTES · PROCESSING: LOCAL
Output · converted 0 CHARS
READ-ONLY · UPDATES ON EVERY KEYSTROKE
Characters in0RAW TEXT
Characters out0BASE64
Bytes encoded0UTF-8 SOURCE
Size change0%+33% IS TYPICAL

Developer Tools · Group 07 of 19

Base64 Tools.

Sixty-four characters are all it takes to push any byte stream through a text-only channel — and this bench speaks both directions fluently. The encoder reads your text as UTF-8 bytes, regroups them into 6-bit packs and writes them out in the standard or URL-safe alphabet, with optional 76-character MIME wrapping. The decoder reads both alphabets, shrugs off line breaks, counts whatever it discards and reassembles the UTF-8 on the other side. Nothing is uploaded, nothing is stored.

  • Tools02
  • Alphabet64 chars
  • Uploads0
  • Backendnone
  • Costfree
In order, 01 → 02

Two directions, one 64-character alphabet.

( 01 )

The pipeline is honest about its steps: your text is first read as UTF-8 bytes — so Persian, euro signs and emoji all survive as real byte sequences — then every three bytes are regrouped into four 6-bit packs and mapped onto the 64-character alphabet. Two toggles shape the output: ⏎ wrap at 76 breaks the result into MIME-style lines for email and PEM bodies, and −_ URL-safe swaps + and / for - and _ and drops the = padding, per RFC 4648. The Size change stat reports the exact toll: three bytes become four characters, so payloads typically grow by a third.

Example

Hello, stars! ★

SGVsbG8sIHN0YXJzISDimIU= the ★ rides along as three UTF-8 bytes → four Base64 characters.

Use it for data URIsJWT payloadsemail attachmentsembedded SVG

The trip home, built to be unshockable. The decoder auto-detects both alphabets — - and _ are quietly remapped to + and / — strips = padding, and with the ␣ ignore whitespace toggle on it folds wrapped, multi-line payloads back together before decoding. Anything outside the alphabet is discarded and counted in the Discarded stat rather than crashing the run, and the byte buffer is reassembled as UTF-8. The verdict cell tells you how it went: CLEAN when the bytes formed valid UTF-8, LOSSY when the payload was raw binary and each byte was mapped to its Latin-1 character instead.

Example

SGVsbG8sIHN0YXJzIQ==

Hello, stars! padding stripped · 14 bytes out · verdict CLEAN.

Use it for reading data URIsJWT segmentsemail payloadsAPI debugging

Encoding rules · the encoder works in two steps — UTF-8 first, then Base64 — so every character becomes its real byte sequence before packing · every 3 bytes become 4 characters of 6 bits, padded with = to a multiple of four in standard mode · URL-safe mode uses - and _ and drops the padding entirely, per RFC 4648 · wrap mode breaks lines at 76 characters, MIME style · the decoder reads both alphabets automatically, strips padding and, with the toggle on, ignores all whitespace before decoding · characters outside the alphabet are discarded and counted — the run never fails · decoded bytes are reassembled as UTF-8; when they don't form valid UTF-8 the verdict flips to LOSSY and each byte maps to its Latin-1 character · encode then decode and you're home, byte for byte · ⇄ Output → Input feeds any result straight back for the return trip

The privacy promise

Paste anything. We couldn't read it even if we wanted to.

This page has no backend and no database. Every byte packed, every character unpacked and every verdict issued just now was computed by JavaScript inside your own browser tab — your payload never traveled a single centimeter of cable. Close the page and it's gone for good.

✕ SERVER · DATABASE · LOGS · ANALYTICS
  • Databasenull
  • Backendnone
  • Payload uploads0
  • Session logs0
Questions

Asked often, answered plainly.

( 02 )
Why is the Base64 output about 33% larger than my input?

That's the fixed price of text-safety, baked into the scheme itself. Base64 regroups every 3 bytes (24 bits) into 4 characters of 6 bits each, because 64 values are all that fit comfortably through any text channel — email bodies, URLs, JSON strings, source code. Three bytes in, four characters out, so the payload grows by a third. The Size change stat on the bench shows the exact figure for your input, padding included.

What is URL-safe Base64?

Standard Base64 uses + and / — both of which carry meaning in URLs and query strings, where + can read as a space and / as a path separator. The URL-safe variant defined in RFC 4648 swaps them for - and _, and usually drops the = padding since its length can be recomputed. Flip the −_ URL-safe toggle on the encoder to produce it; the decoder on this page reads both alphabets automatically, padding or no padding, so you never have to choose a direction.

Can I encode images or binary files here?

This bench is built for text payloads. What you paste is read as UTF-8 text, so raw binary dropped into the textarea would be interpreted as characters first, and its original bytes wouldn't survive the trip. For images and files, use a file-based converter. For JSON, JWT segments, CSS snippets, SVG source, config dumps and every other text payload, this bench is exactly the right tool.

What does the LOSSY verdict mean?

It means the decoded bytes don't form valid UTF-8 — which usually happens when the original payload was raw binary rather than text, or when the Base64 was truncated. Instead of failing, the decoder maps each byte to its Latin-1 character so you can still see what came out, and the red LOSSY verdict tells you not to trust those characters as real text. CLEAN means the bytes reassembled into perfect UTF-8 and what you're reading is exactly what was encoded.

Is my data saved anywhere?

No. IrisTool has no backend and no database. Encoding happens inside your browser tab and the payload disappears the moment you close or refresh the page. There is nothing to leak, because nothing is ever collected.