Encode / Decode Workbench

Base64, hex, URL, HTML, Unicode, Base32, quoted-printable, MIME headers, PowerShell -EncodedCommand, gzip/deflate (SAML), punycode, ROT and XOR — auto-detected, chainable and shareable as a link.

Free · no sign-up · updated

Runs entirely in your browser. Nothing you enter leaves this page.

requests since opened: 0
Verify it yourself

This page is served with a security policy your browser enforces: it cannot open connections or load anything from other sites — not even to us.

  1. Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
  2. Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
  3. See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
  4. Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).

tools v0.9.1 · build 0efa119

How to use
  1. Paste text. A suggested decode step appears if the format is recognised.
  2. Add steps to chain them (e.g. Base64 → inflate → XML), or press Auto-decode.
  3. Copy the output, or the equivalent shell command to cross-check.

Steps

No steps yet — the output below is your input unchanged.

    Output 0 bytes

    Why encodings stack up

    Each layer solves a transport problem: Base64 carries binary data through text, percent-encoding makes text safe in URLs, deflate makes it small, UTF-16 is how Windows stores strings. Real data therefore arrives in layers — a SAML redirect is deflate inside Base64 inside URL encoding. Attackers use the same layers on purpose, because each one hides the next from simple filters.

    How Auto-decode decides

    Every step checks the bytes, not just the characters: the gzip (1F 8B) and zlib signatures, UTF-16 zero bytes, the Base64, Base32 and hex alphabets, and whether the result is readable text. Auto-decode applies the best match, repeats, and stops after eight layers or as soon as a step changes nothing. You can always add, change or remove steps by hand, and each step shows its own error if the data does not fit.

    Decompression is capped at 50 MB, so a small “zip bomb” cannot freeze the tab, and binary results are shown as a hex dump instead of garbled text.

    Share the recipe, not the data

    “Share these steps” copies a link with the chain after the # — the part of a URL browsers never send to a server. A colleague who opens it gets the same steps with an empty input, so the data itself never travels in the link. Including the input is possible, but opt-in, size-limited and refused for anything that looks like a credential. For a single common format, the focused pages (PowerShell, punycode, URL, hex, Base32, quoted-printable) start with the right step already in place.

    Common questions

    How do I decode a PowerShell -EncodedCommand?

    Paste the whole command line or just the encoded part: it is detected automatically and decoded from Base64 as UTF-16LE, the way PowerShell reads it. This comes up often in incident response.

    What does Auto-decode do?

    It repeatedly detects the encoding and adds the right step — for example Base64, then URL decoding, then raw deflate for a SAML redirect — and stops when nothing more can be decoded.

    What is a look-alike domain?

    A domain that uses letters from other alphabets to imitate a real one, such as a Cyrillic “а” in “аpple.com”. Punycode (xn--) domains are decoded and flagged when they imitate a well-known name.

    Known limitations
    • Text is read as UTF-8; binary output is shown as hex.
    • Decompressed output is capped at 50 MB.
    • Auto-detect is a best guess on very short inputs.
    • Browser extensions can read any page — use a private window for sensitive data. How the lock works

    Related reading on CipherMind

    Standards & references