CyberChef

Last reviewed Aug 26, 2026 · 736 words

CyberChef is a single HTML page with its JavaScript bundled in, so self-hosting it means serving a directory of static files and nothing else: no database, no backend, no accounts, and 128 MB of RAM that is really the browser's, not the server's. Everything you paste into it stays in your browser tab. That property is the reason to host your own copy rather than use GCHQ's public instance, and it matters most in exactly the places CyberChef gets used: incident response, malware triage, and debugging production data you should not paste into a random website.

Two ways to deploy, both under a minute

The official container image is the least effort:

services:
  cyberchef:
    image: ghcr.io/gchq/cyberchef:latest
    ports:
      - "8000:80"
    restart: unless-stopped

The alternative is to download the release zip from the project's GitHub releases, unzip it into a directory, and point any web server at it. Under Caddy that is root * /srv/cyberchef and file_server, which also gets you TLS. Both give you the same thing, and since there is no state there is nothing to back up beyond the directory; an update is a new image tag or a new zip. It also works fully offline: the release zip on a USB stick, opened as a local file, is a legitimate deployment for an air-gapped analysis box.

The recipe model is what you are learning

The left column lists operations, a few hundred of them. Drag operations into the middle column to build a recipe; input goes top right, output appears below. Auto Bake re-runs the recipe on every keystroke, which is what makes it feel like a calculator rather than a script. The sequences that come up constantly are short. A suspicious PowerShell one-liner is From Base64 then Decode text as UTF-16LE. A gzipped, base64-encoded log payload is From Base64 then Gunzip. A token is JWT Decode. A blob of unknown provenance gets Magic, which tries encodings and reports what it thinks it found, and it is right often enough to be the first thing I reach for.

Operations take arguments (a key, a delimiter, a regex) that you set inline, and Register can capture a value from the data mid-recipe and feed it into a later step, which is how you decode a payload whose XOR key sits in its own header.

Recipes live in the URL, which is useful and dangerous

Save Recipe encodes the whole recipe as a string, and the share link encodes the recipe plus the input into the URL. That is handy for handing a colleague "here is exactly how I decoded this", and it is also how people accidentally paste a customer's data into a ticket. Share the recipe, not the input, unless the input is already public. Long inputs also blow past URL length limits in some browsers, so for anything beyond a few kilobytes save the recipe and send the file separately. On a self-hosted instance the link points at your server, which is another reason to run one.

The browser is the limit

Everything runs in the tab's JavaScript, so the ceiling is your machine's memory and patience. Files of a few hundred megabytes usually work; multi-gigabyte files do not, and operations like entropy analysis or a regex across a large binary will lock the tab. For those, the same operations are exposed through a Node.js library, so a one-off script or a batch job can use CyberChef's implementations without the UI. For a dev team the sibling tool is IT-Tools, which covers the everyday conversions (UUIDs, hashes, JWTs, cron expressions) with a cleaner interface and far fewer options; running both in the dev tools stack is common and cheap.

What I'd do

Deploy the container behind Caddy on whatever host runs your other internal tools, pin it to a release tag, and bookmark it on the team wiki with a one-line rule: nothing leaves the browser, so this is where sensitive blobs get decoded. Learn Magic, From Base64, Gunzip, and the Extract operations first; that handful covers most of what turns up. Keep IT-Tools next to it for the boring conversions, and reach for the Node library when a file is too big for a tab.