A schema-aware compression engine for SAP IDoc, EDI, and business data — verified to beat plain zstd/brotli by 30–55%, and the W3C EXI standard itself by 33%. Try it live below.
Open the web app — sign in with Google and it's ready.
One window, two explicit modes — nothing to auto-detect, nothing to get wrong:
⤓ Compress ⤑ Decompress
.schemazip back into Decompress and get the exact original back, checksum-verified before it's ever sent to you.General-purpose compressors like zstd, brotli, and gzip treat every file as an undifferentiated stream of bytes. SchemaZip doesn't — it looks at the actual structure of your records first (a batch of SAP IDoc line items, an Excel export, a CSV of transactions), transposes repeated fields into columns, delta-encodes and bit-packs numeric sequences, dictionary-encodes categorical values, and then hands the result to a general-purpose backend (zstd or brotli, whichever wins) for final entropy coding.
The result: it strips out structural redundancy a byte-level compressor can't see, on top of whatever that compressor already does well. That combination is what produces the numbers below.
Every result — in this write-up and in the live tester below — is round-trip verified: SchemaZip compresses, immediately decompresses, and checks the output matches the original byte-for-byte before the number is ever shown. If a mode ever fails that check, the app says so instead of hiding it.
Efficient XML Interchange (EXI) is the W3C's own binary XML standard, purpose-built for exactly this kind of data. Tested head-to-head using EXIficient (the open-source reference implementation) — including EXI's schema-informed mode, which gets an XSD describing the exact structure in advance, an advantage SchemaZip never gets — SchemaZip still came out ahead on every single file:
| Method | Total (28 files) | vs. raw XML |
|---|---|---|
| Raw XML | 550,146 bytes | — |
| EXI, schema-less | 75,428 bytes | 86.3% smaller |
| EXI, schema-less + zstd | 53,868 bytes | 90.2% smaller |
| EXI, schema-informed | 56,032 bytes | 89.8% smaller |
| EXI, schema-informed + zstd (EXI's best) | 37,690 bytes | 93.1% smaller |
| SchemaZip | 25,252 bytes | 95.4% smaller |
This isn't an academic exercise. Every enterprise integration platform — SAP PI/PO, SAP CPI (Integration Suite), MuleSoft Anypoint, Boomi, Azure Logic Apps, a hospital's HL7/FHIR interface engine — spends its entire existence moving, logging, and archiving huge volumes of exactly the kind of data SchemaZip is built for: batches of structurally similar records. IDocs. EDI 850/856/810 documents. FHIR Bundles and Observations. API payloads between trading partners. Every one of those messages typically gets logged for monitoring, archived for compliance, replicated to a DR site, and often copied again into a data lake for analytics. That's not one copy of the data — it's frequently four or five, each sitting in storage, each costing money every single month it exists.
Most of that data is already gzip'd or zstd'd somewhere in the pipeline, and that's genuinely helpful — but general-purpose compression only sees bytes. It doesn't know that field #14 is always one of six status codes, or that field #3 increments by roughly the same amount every row. SchemaZip does, because it looks at the schema first. That's the entire reason it verified 30–55% smaller than plain zstd and 33% smaller than the W3C's own purpose-built XML compression standard earlier on this page — and every percent of that is a percent that was never actually necessary to store or transmit in the first place.
Below is an honest, worked calculation — not a customer case study (none exists yet), just public cloud list pricing (AWS S3 Standard, $0.023/GB/month, August 2026 published rate) combined with SchemaZip's own measured numbers from this page: general-purpose compression already gets structured integration data to roughly 90% smaller than raw (consistent with the 91–94% figures measured directly against our real SAP IDoc/EDI/Excel test corpora above), and SchemaZip verified a further 30–55% reduction on top of that — 40% used below as a representative middle-of-the-range figure.
| Data volume (raw) | Uncompressed storage cost/yr | Already on plain zstd (~90% smaller) | + SchemaZip on top (further ~40% smaller) | Extra $ saved/yr by adding SchemaZip |
|---|---|---|---|---|
| 1 TB | $276 | $27.60/yr | $16.56/yr | $11.04 |
| 10 TB | $2,760 | $276/yr | $165.60/yr | $110.40 |
| 100 TB | $27,600 | $2,760/yr | $1,656/yr | $1,104 |
| 1 PB | $276,000 | $27,600/yr | $16,560/yr | $11,040 |
| 10 PB | $2,760,000 | $276,000/yr | $165,600/yr | $110,400 |
1 PB–10 PB of retained integration/message data is not exotic at this scale — a large hospital network keeping years of FHIR bulk-export archives for regulatory retention, or an enterprise SAP landscape logging every IDoc/EDI message across dev/test/prod/DR for a multi-year audit window, routinely accumulates into that range. The right-hand column is money that was being spent for zero benefit — bytes nobody was ever going to read again, sitting in storage, every month, indefinitely.
Storage is only half of it. Cross-region replication, DR failover sync, and any egress to a partner outside your cloud provider's network typically cost more per GB than storage itself (commonly $0.05–$0.09/GB on major clouds) — and every one of those transfers is moving whatever size the payload actually is. A 40% smaller payload is a 40% smaller egress bill on every single transfer, every day, for as long as the integration runs.
Healthcare is arguably the single best fit for this. FHIR Bulk Data Export ($export operations under SMART Backend Services) routinely produces enormous NDJSON files — thousands of near-identical Patient, Observation, Claim, and Encounter resources, exactly the "batch of structurally similar records" shape SchemaZip is built around. Regulatory retention for clinical records commonly runs 6–10+ years depending on jurisdiction and record type, so this isn't a one-time archive — it's a continuously growing pile that a health system pays to store for a decade or more.
How to implement it: insert SchemaZip as a compression step immediately after the bulk-export job generates its NDJSON output and before it lands in long-term blob storage (Azure Blob, S3, GCS) — a straightforward addition to whatever ETL/orchestration already runs the export (Azure Data Factory, AWS Glue, a scheduled job). For data already sitting in archival storage, it's a one-time re-compression batch job: decompress, verify, re-compress with SchemaZip, replace. Because every result is round-trip verified before it's trusted, this is safe to run against records nobody wants to accidentally corrupt.
CPI retains message processing logs and payload traces for monitoring and audit — that consumes the tenant's message store quota directly, and running over it means paying for additional capacity or cutting retention short. SAP landscapes built on IDoc/EDI messaging (the exact data shape this page has been testing all along) generate huge volumes of near-identical structured messages every single day.
How to implement it: CPI iFlows run on the JVM (Groovy/Java script steps), not Python, so the practical integration pattern is the same one already proven live on this page: SchemaZip runs as a small internal REST microservice (this page's own live tester is deployed exactly that way), and a CPI iFlow calls it via a standard HTTP Receiver adapter or Script step — compress right before a message is written to persistent storage or handed off to an archive/data-lake step, decompress on the way back out if it's ever needed again. No change to CPI's own message processing logic required, just one additional call at the boundary where data is about to be persisted.
Same shape, same fix. Mule flows processing high volumes of XML/JSON/EDI frequently persist payloads to Object Store, a database, or external storage for replay and audit — and like CPI, Mule runs on the JVM, so it can't call SchemaZip's Python logic directly either.
How to implement it: the identical microservice pattern — an HTTP Connector step in the Mule flow calls the SchemaZip service before a payload is written to Object Store or an external archive, and calls it again (decompress) on retrieval. Because the service is stateless and payloads never persist beyond one request (see the live tester's own privacy note above), it drops into an existing flow as a single new HTTP step with no architectural rework.
When two organizations exchange data directly — EDI over AS2/SFTP, partner APIs, a managed file transfer (MFT) gateway — every byte crosses a network, often a metered one, and frequently gets archived on both ends independently. This is the case where compression saves money twice over: once in transit (smaller payload, less bandwidth/egress cost on both sides) and again in storage (both parties separately retaining the same shrunk data for their own compliance needs).
How to implement it: this only works cleanly when both ends agree on the format, which makes it the natural fit for a B2B gateway or MFT platform that already sits between the two organizations — compress on the sending side as the very last step before transmission, decompress on the receiving side as the very first step after it arrives, with the SchemaZip service called from whatever scripting/transformation capability the gateway already exposes (most enterprise MFT tools support custom pre/post-processing steps or webhooks for exactly this kind of thing).
In every case above, the implementation is the same idea: compress right before data is persisted or transmitted, decompress right before it's read or processed, and do it through a small stateless service called from whatever step your platform already exposes for exactly this purpose — no rearchitecting, because the live tester on this very page already proves the service pattern works.
Honest caveat, consistent with the rest of this page: the table above is an illustrative calculation from public cloud pricing and our own measured ratios, not a verified customer deployment — none exists yet. The gains are real and reproducible (test them yourself below), but they scale with how repetitive your actual data is, exactly as described in "Honest Caveats" below. Compute cost for running the compression itself is real too, though at these storage/egress numbers it's a rounding error by comparison — SchemaZip's own "Fast Mode" measured in milliseconds even on tens of thousands of records earlier in testing.
SchemaZip's structural transform pays off when there's structure to exploit: repeated field names, batches of similar records, numeric or categorical columns. On a handful of genuinely unique records — a 3-message chat log, one-off prose — there's very little redundancy for any compressor to find, and SchemaZip typically ties the best general-purpose method rather than beating it. That's an honest information-theoretic limit, not a bug, and the tester below will show you exactly that when it happens.
Upload a .json, .csv, .xml (SAP IDoc / EDI), .xlsx, .docx, or .txt file and see how SchemaZip compares to gzip, bz2, lzma, zstd, brotli, and 7-Zip on your actual data — verified live, not a canned demo.
Drop a file here, or click to choose one
.json · .csv · .xml · .xlsx · .docx · .txt — up to 20MB
Your file is processed in memory on the server for this one request only — never written to persistent storage, never logged, never retained. Max 20MB / 20,000 records per file for this demo. Files over 1,500 records get a faster (still verified) comparison that skips the slowest methods, to keep results quick on the free tier this runs on.