# GCHQ CyberChef: Browser-Based Data Manipulation for Analysts

> CyberChef runs entirely in the browser with a drag-and-drop recipe builder, but large files hit memory limits and the Magic auto-detection cannot decode every encoding layer.

**gchq/CyberChef** — The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis

- Repository: https://github.com/gchq/CyberChef
- Website: https://gchq.github.io/CyberChef
- Stars: 36,004 · Forks: 4,162
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/gchq-cyberchef

## The recipe model chains operations in a linear pipeline

CyberChef organizes work as a recipe: a sequence of operations dragged from the left panel into the central area. Each operation takes the output of the previous one as its input. The input box accepts pasted text, typed data, or files up to 2GB dragged onto it. The output box displays the final result with offset and length highlighting when you select text in either box. Operations accept arguments and options specific to their function; for example, the AES Decrypt operation requires a key and optionally an IV, while the XOR operation takes a hex or string key. The recipe executes automatically whenever the input or recipe changes unless Auto Bake is disabled. The operations list on the far left contains categorized lists covering encoding, encryption, compression, hashing, parsing, and character set conversion. You can search the list by typing in the search field to immediately filter matching operations.

## Auto Bake cannot keep up with very large inputs

Auto Bake re-runs the entire recipe on every change. With large inputs, the README notes files around 2GB depending on browser, this causes noticeable latency or browser freezing. The feature can be toggled off so you manually trigger execution, but the README does not document any incremental or streaming execution mode. If you work with multi-gigabyte files regularly, the browser memory ceiling becomes a hard limit; there is no server-side fallback or chunked processing documented. Users hitting out-of-memory errors during local builds are told to run `npm run setheapsize` to increase Node's heap, but no equivalent browser-side workaround exists for the hosted version. The 2GB drag-and-drop limit is also browser-dependent; some browsers may fail at lower thresholds.

## Magic auto-detection works only on known encoding patterns

The Magic feature attempts to identify encoding layers using techniques described in the project wiki. When it recognizes a pattern, a magic wand icon appears in the output field. Clicking it applies the detected operation chain automatically. However, the README makes no claim that Magic works on unknown or custom encodings. It relies on a curated set of detection heuristics; proprietary or obfuscated formats will not trigger the icon. Analysts cannot train or extend the detector from the UI; the wiki documents the existing techniques but there is no plugin API for adding new ones. If Magic fails, you must manually search the operation list and construct the recipe yourself. The detection uses multiple techniques but the README does not specify which encodings are covered.

## Local deployment requires Node.js 24 and a specific Docker ulimit

Building from source mandates Node.js v24 exactly; the .nvmrc and package.json browserslist both pin this version. The Dockerfile uses `node:24-alpine` with a multi-stage build: first installing dependencies with `npm ci --ignore-scripts`, then running `npm run postinstall` (which executes Grunt), then `npm run build` to produce static assets in `build/prod`. The build stage requires `--ulimit nofile=10000` during `docker build` because the chromedriver dependency is not compatible with all platforms. The pre-built image at `ghcr.io/gchq/cyberchef:latest` avoids this step but still runs on the same nginx-unprivileged base. There is no ARM-specific image documented; cross-compilation is limited by the chromedriver constraint noted in the Dockerfile comments. The production build outputs to `build/prod` which is then served by nginx.

## Breakpoints and step-through debugging operate on the recipe, not the data

You can set breakpoints on any operation in the recipe to pause before that operation runs, and step through one operation at a time to inspect intermediate output. This is a recipe-level debugger: it shows what the data looks like after each operation, but it does not let you inspect internal state of an operation (such as AES round keys or compression dictionary entries). The README does not describe conditional breakpoints, watch expressions, or variable inspection beyond the input/output highlighting. For analysts reversing unknown protocols, this means you can see transformation results but not the algorithm internals; you would need to pair CyberChef with a separate debugger or disassembler for that depth. Breakpoints persist in saved recipes stored in localStorage.

## Recipe sharing via URL embeds both input and operations

Saving a recipe writes it to localStorage for persistence across sessions. Sharing uses deep linking: the URL encodes the entire recipe and the input data. Anyone opening the link sees the same recipe and input pre-loaded. This is convenient for collaboration but has two consequences. First, URLs grow with input size; there is no documented compression or external reference mechanism, so large inputs produce unwieldy links. Second, the input is visible in the URL, which may leak sensitive data if shared over untrusted channels. The README does not mention an option to share only the recipe without the input, nor does it document URL length limits imposed by browsers or proxies. Recipes can also be saved to a file and loaded later using the Save and Load recipe buttons.

## Client-only execution means no server-side scaling or audit trail

All processing happens in the browser; no data leaves the client. This is a security feature; the README emphasizes that nothing is sent to a server, but it also means CyberChef cannot be used as a backend service. There is no API mode, no batch processing endpoint, and no way to run recipes headlessly at scale. The Node.js entry points (`src/node/wrapper.js` and `src/node/index.mjs`) exist for testing and development, not for production workloads. Teams needing automated, repeatable pipelines must re-implement the logic elsewhere. The Apache-2.0 license permits reuse, but the operation implementations are tightly coupled to the UI framework (CodeMirror, webpack build) and are not published as a standalone npm library for programmatic use. Browser support requires Chrome 50 or later, Firefox 38 or later, or Node.js 24 and later.

## Docker build requires elevated file descriptor limit and Node.js 24 pin

To run CyberChef with Docker, you need Docker Desktop open and running. Build the image yourself with the exact command from the README:
```bash
docker build --tag cyberchef --ulimit nofile=10000 .
```
Then run the container:
```bash
docker run -it -p 8080:8080 cyberchef
```
Navigate to `http://localhost:8080` in your browser. Alternatively, skip the build with the pre-built image:
```bash
docker run -it -p 8080:8080 ghcr.io/gchq/cyberchef:latest
```
To build from source, you need Node.js v24. Clone the repository, install dependencies, and start the development server:
```bash
git clone https://github.com/gchq/CyberChef.git
cd CyberChef
npm install
npm start
```
The development server runs at `http://localhost:8080` with live reload. For a production build, run `npm run build` which outputs to `build/prod`. Common tasks include `npm test` for test suites, `npm run testui` for browser tests, `npm run lint` for linting, and `npm run newop` to scaffold a new operation. The `--ulimit nofile=10000` flag is mandatory during docker build because the chromedriver dependency is not compatible with all platforms. The .nvmrc and package.json browserslist both pin Node.js v24 exactly; no other version is documented as supported.

## Conclusion

Analysts who need quick, offline-capable data transformations without installing CLI tools will benefit. Teams needing server-side processing or guaranteed Magic detection on unknown formats should verify limitations first.

## FAQ

### What are the uses of CyberChef?

CyberChef performs encoding (Base64, XOR), encryption (AES, DES, Blowfish), compression, hashing, IPv6 and X.509 parsing, and character set conversion in a browser-based recipe builder.

### Is CyberChef safe to use?

Yes, all processing runs client-side in the browser with no data sent to any server, as stated in the project's security documentation.

### Can I run CyberChef locally?

Yes, you can run it locally using Docker with `docker run -it -p 8080:8080 ghcr.io/gchq/cyberchef:latest` or build from source with Node.js 24 via `git clone`, `npm install`, and `npm start`.

### How to use CyberChef magic?

When CyberChef detects a known encoding pattern, a magic wand icon appears in the output field; clicking it applies the detected operation chain automatically.

### How to use CyberChef offline?

Run the pre-built Docker image `ghcr.io/gchq/cyberchef:latest` or build from source with Node.js 24; both work without internet access after the initial pull or clone.

## Sources

- [Official documentation](https://gchq.github.io/CyberChef)
- [Official README](https://github.com/gchq/CyberChef#readme)
- [Project repository](https://github.com/gchq/CyberChef)
- [Release notes](https://github.com/gchq/CyberChef/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gchq-cyberchef