Live benchmark · real files · runs on your machine

Bring your own file.

Storing data as a shape only helps when the data has a shape. This page measures that on real files: a photograph, its decoded pixels, a text document, and anything you drop in. Each one is sealed as a generating rule plus the correction that makes it exact, checked for losslessness with SHA-256, and put against gzip on the same bytes.

Expect to watch it lose. On text, on already-compressed files, and on real photographs, gzip and PNG win, and my own testing says so. The point of running it on real data is to find the boundary rather than to hide it. The synthetic fields at the bottom are where the method is designed to win, and the contrast between the two tables is the actual result.

Real files

Ready.

Drop a file here, or click to choose one.
CSV, JSON, WAV, BMP, log, binary, anything. It never leaves your browser.

How to read the table

Raw is the file as it sits on disk. gzip is that file compressed the ordinary way, which is the number to beat. Shapes fitted says how many 1 KB blocks the file was cut into and which shapes won most often: a flat line, a slope, a curve or a wave. Rules + corrections is the total cost of this approach: the coefficients for every block, plus the packed differences between what the shapes predicted and what the file actually contained. vs gzip above 1.00 means the shapes did better. Rebuild exact hashes the reconstruction against the original, so "yes" means nothing was lost or approximated anywhere. Verdict is the plain reading of the vs-gzip column.

File	Type	Raw	gzip	Shapes fitted	Rules + corrections	vs gzip	Rebuild exact	Verdict
Press run, or drop a file.

Numbers here will not match the written-up figures exactly. This page uses the browser's own gzip and a JSON-encoded rule; the Node suite uses raw deflate at level 9 and a tighter rule encoding, which is worth roughly 20% on the synthetic rows. Same mechanism, different packing, and both are reported rather than the better one being quoted alone.

Live data from a public API

Real measurements, fetched from Open-Meteo when you press the button: a year of hourly temperature readings for St. George, Utah. Nothing synthetic, nothing chosen to flatter the method. This is the case it is actually for: a physical quantity that rises and falls on a daily cycle, so a shape genuinely describes it.

Roughly 8,760 hourly readings.

■ measured temperature ■ the daily shape fitted to each block ■ what the shape missed

How it is held	Bytes	Against the shape	Notes
Press the button.

Synthetic fields, where geometry is the whole content

The same machinery on data that is a shape. These are the cases the written-up figures come from, and they are honest only because the table above exists next to them.

Field	Raw	gzip	Rule	Correction	Capsule	vs raw	vs gzip	Lossless
Filled by the same run.

How the fit is chosen

For an arbitrary file the page has no idea what shape the data is, so it tries a small, disclosed set of candidate rules over the byte stream and keeps whichever produces the smallest capsule: a constant, a straight line, a quadratic, and a sinusoid whose frequency is found by a coarse search. Each fit is stored as a handful of coefficients.

That is deliberately a weak library of shapes. A serious implementation carries far more, and choosing well for a given file is the hard part of the problem. What this page can honestly show you is the mechanism and the boundary: rule plus correction is exact, and the capsule shrinks only in proportion to the geometry actually present.

node dimensional-programming.test.js → 14 of 14 proofs, limits included
node geometric-transport.js → the capsule table, SHA-256 verified per row

Back to the write-up Ask me for the scripts