{{ summaryTitle }} · {{ summaryValue }} · {{ summaryLine }} · {{ algorithmLabel }} · Source {{ formatBytes(sourceBytes) }} · {{ resultsReady ? 'Archive current' : 'Run required' }}

Source {{ flowVisual.methodLabel }} {{ flowVisual.outputLabel }}
File compression setup
The safe text sample keeps the cold-load result inspectable. Replace it with one file of your own.

{{ dragActive ? 'Drop the file here' : selectedFileName }}

{{ sampleSource ? 'Browser-created text sample' : 'Local file' }} · {{ formatBytes(sourceBytes) }}

{{ sourceStatus }}

Choose for receiver compatibility first; the result ledger shows the exact wrapper used.
{{ levelDisplay }}
{{ levelHelp }}
.{{ outputExtension }}
Use a base name without path separators or an archive extension.
This only changes ZIP Deflate behavior for known compressed extensions.
{{ params.smart_store ? 'On' : 'Off' }}
MB
0 keeps one artifact. Positive values use decimal megabytes (1 MB = 1,000,000 bytes).
{{ exportAnnouncement }}
MetricValueReview useCopy
Compression is in progress or the current settings require a new run.
{{ row.metric }}{{ row.value }}{{ row.use }}

Download artifact

{{ deliverySummary }}

Integrity

{{ sha256Hex || 'SHA-256 appears after compression completes.' }}

Reassembly note

{{ reassemblyNote }}

{{ exportAnnouncement }}

File compression can reduce storage and transfer time, while an archive wrapper gives the receiver a recognized container or stream. Those are related but different jobs: TAR packages bytes without compressing them, gzip and Brotli compress a byte stream, and ZIP can either store or Deflate a file inside a ZIP container.

Text, logs, and repetitive data often shrink well because they contain repeated byte patterns. JPEG, video, PDF, font, and existing archive formats are usually already compressed, so another compression pass may save little or even make the result larger after wrapper headers are added.

Archive and compression format comparison
OutputWhat it containsTypical handoff consideration
ZIP DeflateOne file in a ZIP container, compressed unless smart-store keeps known compressed bytes unchangedBroad desktop compatibility
ZIP StoreOne file in a ZIP container without compressionPackaging without recompression
TAROne file in an uncompressed ustar archiveUnix-style packaging; output may be larger
TAR.GZ or TAR.BRA one-file TAR archive compressed as a gzip or Brotli streamReceiver must support both wrapper and compression method
GZ or BRThe source bytes as one compressed stream, without a TAR containerRepresents one file rather than a multi-entry archive

A higher level asks the compressor to spend more effort looking for a smaller representation; it cannot guarantee a smaller result. Compatibility should be chosen before level. A receiver that cannot open Brotli or a split archive gains nothing from the extra size reduction.

Splitting happens after the complete archive is built. Numbered parts are not independent archives, and every part is needed in numeric order to reconstruct the original output. The SHA-256 digest identifies the complete archive before splitting; it can detect a changed reconstruction but does not encrypt the contents or prove who created them.

How to Use This Tool:

Choose the format the receiver can open, then compare the complete output with the original file.

  1. Choose or drop one non-empty Source file. Extra dropped files are ignored because one file is active at a time.
  2. Select the Archive format and a compression level where the format supports one. TAR and ZIP Store do not use the level setting.
  3. Enter a safe Output name without path separators or an archive extension.
  4. Open Advanced to enable ZIP smart-store or set a decimal-megabyte Part size. Use 0 MB to keep one artifact.
  5. Select Compress file, then check Archive report for output bytes and size change. Re-run after changing the format, level, smart-store setting, or part size.
  6. Download the archive or every numbered part from Delivery record, and keep the SHA-256 value when the receiver needs an integrity check.

Interpreting Results:

A positive saving percentage means the complete archive has fewer bytes than the source. A negative value means wrapper or compression overhead made it larger. That can be a valid result when the chosen container is required for compatibility.

  • Archive/source ratio below 1 means shrinkage, 1 means equal byte size, and above 1 means growth.
  • Output size describes the complete archive before optional splitting; parts should total the same number of bytes.
  • SHA-256 covers the complete archive, not each numbered part separately.
  • A good size result does not prove that the receiver can extract the format. Test extraction in the target environment when the handoff matters.

Technical Details:

The operation begins with the exact source bytes. The selected wrapper determines whether those bytes are stored directly, placed in a TAR record, compressed as a stream, or combined with both packaging and compression.

Transformation Core

File compression transformation paths
ModeTransformation pathLevel range
ZIP DeflateSource file → ZIP entry → Deflate, or Store for a known compressed extension when smart-store is on0 to 9
ZIP StoreSource file → uncompressed ZIP entryNot used
TARSource file → one POSIX ustar entry with 512-byte records and end blocksNot used
TAR.GZSource file → TAR bytes → gzip stream0 to 9
TAR.BRSource file → TAR bytes → Brotli stream0 to 11
GZSource bytes → gzip stream0 to 9
BRSource bytes → Brotli stream0 to 11

ZIP smart-store recognizes common image, media, document, font, and archive extensions and uses an uncompressed ZIP entry for them. This is an extension-based policy, not a content scan. Brotli modes depend on the browser's Brotli compression-stream support; an unsupported browser reports that the format is unavailable.

Formula Core

All size metrics use the complete archive byte count. Let S be source bytes and A be archive bytes.

Bsaved=SA P=SAS×100 R=AS

The report shows P to two decimal places and R to four. A source file must contain at least one byte. If a positive part size is entered, it is converted with 1 MB = 1,000,000 bytes and the archive is sliced sequentially into .part01, .part02, and later pieces. No split occurs when the archive already fits in one part.

Integrity mechanism

SHA-256 is calculated over the complete archive blob before any split. Reassembly must concatenate every part in ascending numeric order, after which the digest should match the recorded hexadecimal value. Matching proves byte-for-byte equality with that archive value; it is not a password, signature, malware scan, or authenticity certificate.

Privacy, Compatibility, and Safety Notes:

The selected file is read, compressed, hashed, split, and downloaded in the browser; its bytes are not uploaded for processing. The page loads compression and chart code as external resources.

  • No password or encryption is added. Anyone who receives a supported output can read the archived file.
  • Only one file is packaged, even for ZIP and TAR formats that can normally hold multiple entries.
  • Test the downloaded output before deleting the source. For split delivery, test reassembly and SHA-256 verification as well as extraction.
  • Do not assume an archive is safe because it was compressed successfully; scan untrusted files with appropriate security controls.

References: