iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
BurpSqueezer is an open-source Rust command-line tool that converts a Burp Suite XML traffic export into compact, structured Markdown that a person or a large language model can analyze. In the example its author and project report, a capture of about 26.7 MB containing 323 transactions shrank to about 35 KB in the default standard mode. That is one dataset, not a benchmark, and the tool only reshapes traffic you have already captured. It does not send requests to a target.
Why a raw Burp dump does not work as LLM input
The author’s starting point was simple: a large Burp Suite capture from a real testing session was too big to hand to an LLM as-is, and the model could not make useful sense of it. Raw Burp exports repeat the same hosts, headers, cookies, and boilerplate across hundreds of transactions. Most of that repetition carries no security-relevant meaning, yet it consumes the context an analysis would need. The problem is less about file size on disk and more about how much of the content is signal.
BurpSqueezer approaches this as a data-preparation step. It takes the export, applies statistical and heuristic filtering to drop redundant or low-value traffic, and then writes out Markdown that tries to preserve the structure a tester cares about: endpoint relationships, request sequences, and how parameter values propagate from one request to the next.
What BurpSqueezer does and does not do
The boundaries matter as much as the features, so they come first. BurpSqueezer reads a file that you have already exported from Burp Suite. It has no connection to the target, sends no requests, and does not attack anything. The author states this directly: “It is also not an autonomous pentesting tool. It doesn’t send requests or attack the target.”
The output is meant as compact context for inspection, not as a verdict. The project notes that results can miss relationships or security signals, so human review and manual testing remain necessary. The original capture is worth keeping, because it lets you verify a finding against the full transaction or retrieve material the compression left out.
The project’s README also states that BurpSqueezer “is an independent security research tool and is not affiliated with, endorsed by, or developed by PortSwigger.” You still need your own Burp Suite installation to produce the XML export it reads.
Where it fits and where it does not
BurpSqueezer earns its keep on large captures from APIs or applications with real business logic, where requests depend on one another: a login token reused in later calls, an object ID created in one step and modified in another, a workflow that only makes sense as a sequence. Those relationships are what the heuristics try to surface, and they are exactly what a flat transaction list hides.
It is a poor fit for a small, mostly static, or highly repetitive site. If there are few relationships to find, there is little for the analysis to compress around, and reading the capture directly is likely faster. Size alone does not decide the question; structure does.
Choosing a mode
BurpSqueezer offers three modes. They are trade-offs between how much potentially useful information is kept and how small the output becomes, not competing products. The compression figures below are the project’s own, measured on the example dataset described above, and the README says compression varies with the dataset.
| Mode | What it favors | Project-reported compression (single example) | When to pick it |
|---|---|---|---|
peaceful |
Retains more potentially useful information | 347× | You want the most context and can accept a larger output |
standard (default) |
Balance between retention and size | 745× (about 26.7 MB to about 35 KB) | A sensible first pass on a large API or application capture |
apocalyptic |
Selects the strongest structural signals most aggressively | 1,738× | You need the smallest possible context and accept the higher risk of dropping relevant detail |
No mode is objectively best. Start with standard, compare what the output retains against the original capture for a few transactions you already understand, and move toward peaceful if important requests seem to be missing. Use apocalyptic only when size is the binding constraint.
Rank #4
Installing and running it
The project documents a Rust-based install. These steps follow the repository instructions; they were not independently re-run for this article.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →- Install the Rust toolchain on your machine.
- Clone the BurpSqueezer repository, using the location given in the project README.
- From the repository directory, run
cargo install --path . - Confirm the install by running
burpsqueezer --help. - Convert your Burp Suite XML export, for example:
burpsqueezer solve burp_dump.xml --output analysis.md
Three options control the run. --mode accepts peaceful, standard (the default), or apocalyptic. --verbose prints per-stage detail, which helps when you want to see what each filtering step removed. --quiet suppresses progress output, useful in scripts.
Best Value
Checks before you send anything to a model
- Authorization. Use only captures you are permitted to access and analyze. This applies to the Markdown output just as much as to the raw export.
- Sensitive data. Traffic usually contains session tokens, cookies, personal data, and internal hostnames. Compression does not remove these. Review the Markdown and decide whether the LLM service you use is allowed to receive that material.
- Spot-check the output. Pick a few requests from the original capture and confirm they, or their relationships, appear in the Markdown. A missing request is not proof it was unimportant.
- Keep the original. Retain the full XML so you can verify any model-generated observation against the transactions it refers to.
How to read the 745× figure
The headline number comes from a single capture: roughly 26.7 MB, 323 transactions, and about 35 KB of output in standard mode. The project reports it, and the author repeats it in the write-up that introduced the tool. It is not an independent benchmark, and it cannot be extrapolated to another application. A dense, heavily relational API capture may compress well; a sparse or largely static site may not compress by anything close to that ratio, and may not benefit much at all.
Read it as a sign of what the approach can do on a suitable input, and test it on your own capture rather than planning around it.
Where the tool is headed
Repository instructions, releases, and project status can change, so check the README before you rely on a specific command or option. The behavior described here reflects the project documentation as accessed on October 7, 2026, and the author’s introductory post dated September 16, 2026.
The useful takeaway is narrower than the headline. BurpSqueezer does not make an LLM a pentester. It makes a large, redundant traffic log small enough to be read, and it leaves the judgment, the verification, and the testing with you.
Sources: the author’s DEV Community post by vaginskii (September 16, 2026) and the vaginskii/BurpSqueezer project README (accessed October 7, 2026).
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
