Online File Compressor
Compress one local file into a compatible archive or stream and review size change with split delivery plus SHA-256 integrity before downloading.{{ summaryTitle }} · {{ summaryValue }} · {{ summaryLine }} · {{ algorithmLabel }} · Source {{ formatBytes(sourceBytes) }} · {{ resultsReady ? 'Archive current' : 'Run required' }}
| Metric | Value | Review use | Copy |
|---|---|---|---|
| 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 }}
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.
| Output | What it contains | Typical handoff consideration |
|---|---|---|
| ZIP Deflate | One file in a ZIP container, compressed unless smart-store keeps known compressed bytes unchanged | Broad desktop compatibility |
| ZIP Store | One file in a ZIP container without compression | Packaging without recompression |
| TAR | One file in an uncompressed ustar archive | Unix-style packaging; output may be larger |
| TAR.GZ or TAR.BR | A one-file TAR archive compressed as a gzip or Brotli stream | Receiver must support both wrapper and compression method |
| GZ or BR | The source bytes as one compressed stream, without a TAR container | Represents 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.
- Choose or drop one non-empty Source file. Extra dropped files are ignored because one file is active at a time.
- Select the Archive format and a compression level where the format supports one. TAR and ZIP Store do not use the level setting.
- Enter a safe Output name without path separators or an archive extension.
- Open Advanced to enable ZIP smart-store or set a decimal-megabyte Part size. Use 0 MB to keep one artifact.
- 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.
- 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
| Mode | Transformation path | Level range |
|---|---|---|
| ZIP Deflate | Source file → ZIP entry → Deflate, or Store for a known compressed extension when smart-store is on | 0 to 9 |
| ZIP Store | Source file → uncompressed ZIP entry | Not used |
| TAR | Source file → one POSIX ustar entry with 512-byte records and end blocks | Not used |
| TAR.GZ | Source file → TAR bytes → gzip stream | 0 to 9 |
| TAR.BR | Source file → TAR bytes → Brotli stream | 0 to 11 |
| GZ | Source bytes → gzip stream | 0 to 9 |
| BR | Source bytes → Brotli stream | 0 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.
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:
- DEFLATE Compressed Data Format Specification version 1.3, RFC Editor, May 1996.
- GZIP file format specification version 4.3, RFC Editor, May 1996.
- Brotli Compressed Data Format, RFC Editor, July 2016.
- GNU tar and POSIX tar, GNU Project.
- Secure Hash Standard, National Institute of Standards and Technology, August 2015.