Lossless · Structured data · Rust

Structured data.
Less to move.

A compressor built around the repetition in logs, JSON and tabular data. Reuse record structure, pack recurring values, and restore every original byte.

Get PIZD Explore the results →

Native Rust and optional Zstandard-backed engines. Self-contained archives with --standalone.

Logs / JSON / CSVStandalone .pizdCLI + local dictionaries
MEASURED ARCHIVE SIZEVerified benchmark

Smaller archives.
A visible trade-off.

30 public excerpts · density settings · all sources included

Measured comparison available on the benchmarks page.

Size, encoding time and verified decoding are reported together.

View the full comparison and methodology →

—Hybrid thin stored size vs Zstd L9
—Hybrid thin encoding cost vs Zstd L9
30 sourcesSystem logs, HTTP, JSON events & parser fixtures

The structure is
part of the data.

Repeated field names, timestamps and related values are useful signals. PIZD separates reusable structure from changing values before selecting a lossless representation.

01 / MODEL

Work across records.

Structural projections and column models capture repeated layouts and value coherence in logs and structured records.

02 / ENCODE

Choose the trade-off.

Use default, fast or thin profiles. Native encoding keeps a Rust pipeline; Hybrid uses Zstandard as a backend.

03 / RESTORE

Keep every byte.

Standalone archives carry what they need. Verification checks the restored contents; dictionary sharing is optional.

Useful gains.
Honest boundaries.

A compressor should earn its place on your workload. Start with measured examples, then compare size and throughput on your own files.

Where to evaluate PIZD

  • HTTP and application logs with recurring record layouts.
  • JSON events and tabular exports with repeated keys or values.
  • Archival and transfer tasks where fewer bytes can justify more encoding work.

Where alternatives can win

  • Zstandard often wins ingestion-speed comparisons.
  • Brotli can produce smaller archives on some log and text sources.
  • Small or irregular records may not repay model overhead. Already-compressed data is a secondary use case.

Examples are labeled by source and preset. They are illustrations, not a substitute for the complete panel.

One archive.
Start standalone.

No dictionary service is required for this workflow. Keep the original file, compress it, then restore and compare.

# Compress without a dictionary service
pizd compress access.log --standalone --offline --thin -o access.pizd

# Restore and verify the archive checksum
pizd decompress access.pizd --offline -o restored.log

# Independently compare the original and restored files
cmp access.log restored.log

Get a build you can trace.

Use the downloads page for release availability, build instructions and provenance verification.

Pick a profile.

Start with default. Use --fast to favor speed or --thin to spend more effort on size.

Measure your workload.

pizd bench input.log compares PIZD with other codecs. Check decoding time as well as archive size.

Read the getting-started guide →

Evidence you can inspect.

The latest benchmark uses the same public excerpts for every codec. Raw files, source identities, presets and limitations remain available without filling the front page with development logs.

Current codec comparison

Default, fast and thin. Size, encoding time and verified decoding.

Explore results →
Zenodo preprint

Deposited on Zenodo; not submitted to arXiv.

Open the paper →
Methods and development archive

Source provenance, original CSVs, independent checks and historical investigations.

Inspect the evidence →

Measured version and source version

One result, one source snapshot.

The interactive public comparison is the frozen 6.0.0-rc1 run; its version is retained. The separate 18-input generated panel measures 6.0.0-rc9. Neither is a fresh comparison of the isolated rc9 candidate.

The rc9 density candidate reduces public30 Native thin/template archives from 687,537 to 657,356 bytes (4.39%), but verified in-process decoding takes 5.778 times longer in its paired audit. This is a separate candidate pending integration review, not a universal speed gain. Familiar inputs and same-family later windows do not establish independent generalization.

The engineering contribution combines exact-layout models, exception-aware field dependencies and complete-cost representation choices. These build on established compression methods. No matched comparison with specialized log compressors or new entropy-coding theorem is claimed.

Publication claim audit → · Candidate sizes, CPU costs and source identities →