The Complete Guide to File Compression: PDF, Image, Video & Document Compression Explained

The Complete Guide to File Compression: PDF, Image, Video & Document Compression Explained File compression is one of the most common needs in everyday work. An email attachment exceeding 25MB won't send, a PDF is too large to upload to a system, a folder of high-res photos is eating up your disk space — these scenarios all point to the same problem: the file needs to be smaller. But "compression" means very different things in different contexts. Zipping files with 7-Zip is compression. Shrinking a 5MB photo to 500KB is also compression. Converting a 4K video to 720p? That's compression too. The technical principles behind each are fundamentally different, and so are their use cases. This guide covers the core principles of file compression and walks through PDF compression, image compression, video compression, OFD compression, and enterprise data compliance — helping you understand the logic behind each file type and choose the right approach. At its core, file compression is about representing the same information with less data. Based on whether information is lost, compression falls into two categories: graph TD A[File Compression] --> B[Lossless] A --> C[Lossy] B --> B1[DEFLATE<br/>ZIP/gzip] B --> B2[LZMA/LZMA2<br/>7z format] B --> B3[PNG Filter + DEFLATE] C --> C1[DCT<br/>JPEG core] C --> C2[Quantization<br/>coefficient rounding] C --> C3[Inter-frame Prediction<br/>H.264/H.265] B1 --> B1a[Text/Code/Archives] B2 --> B2a[High-ratio Archives] B3 --> B3a[Lossless Images] C1 --> C1a[JPEG Images] C2 --> C2a[MP3 Audio] C3 --> C3a[MP4 Video] style B fill:#4CAF50,color:#fff style C fill:#FF9800,color:#fff Lossless compression reduces file size while ensuring the decompressed data is byte-for-byte identical to the original. It works by eliminating redundancy — for example, a sequence like AAAAABBBCC can be encoded as 5A3B2C, instantly halving the storage space. Common algorithms include: DEFLATE: The core algorithm used by ZIP/gzip, combining LZ77 + Huffman coding LZMA/LZMA2: Used by 7-Zip's .7z format, offering higher compression ratios than DEFLATE PNG filtering + DEFLATE: Applies row-level filtering to image data before DEFLATE compression Typical applications: ZIP/7z archive compression, PNG images, FLAC audio. Lossless compression is ideal for text, code, spreadsheets — anything where losing even a single bit is unacceptable. Lossy compression achieves smaller sizes by discarding information that human eyes or ears are less sensitive to. For example, a 4000×3000 photo displayed on a 1920×1080 screen doesn't need all those extra pixels — they can be safely discarded. Common techniques include: DCT (Discrete Cosine Transform): The core of JPEG, converting images from the spatial domain to the frequency domain and discarding high-frequency components Quantization: Rounding frequency coefficients at a given precision — lower precision means smaller files but more loss Inter-frame prediction: Used in video compression (H.264/H.265) to leverage similarity between consecutive frames, encoding only the differences Typical applications: JPEG images, MP3 audio, MP4/H.264 video. Lossy compression is suited for images, video, audio — media where some quality loss is acceptable. Understanding the distinction between these two approaches is the foundation for choosing compression tools and parameters. Most document compression (PDF, Word) uses both methods simultaneously — lossless for text, lossy for embedded images and video. Many developers confuse two fundamentally different compression needs: graph LR subgraph Archive Compression A1[File A 30MB] --> R1[Package] A2[File B 20MB] --> R1 A3[File C 10MB] --> R1 R1 --> O1[archive.zip<br/>59MB<br/>only 1% reduction] O1 --> N1[After extraction<br/>original sizes restored] end subgraph Content Compression B1[PDF file 50MB] --> R2[Content optimization] R2 --> O2[compressed.pdf<br/>8MB<br/>84% reduction] O2 --> N2[Open directly<br/>no extraction needed] end style R1 fill:#2196F3,color:#fff style R2 fill:#4CAF50,color:#fff style O1 fill:#FFC107 style O2 fill:#8BC34A,color:#fff Dimension Archive Compression (7-Zip/WinRAR) Content Compression (Specialized Tools) What it does Packages files into .zip/.7z/.rar Directly reduces individual file size Target Collections of any files PDF, images, video, Office documents Method Lossless (redundancy elimination) Lossy + lossless hybrid (content optimization) Usage Must extract before use Open directly after compression Typical scenario Bundling multiple files for transfer Reducing individual file size The bottom line: if your problem is "this file is too big to email," you need content compression, not archive compression — because when the recipient extracts the .zip, the file inside is still the same size. # Archive compression: file size unchanged, just packaged Original 50MB PDF → 7z archive → 49MB (only 2% reduction) # Content compression: directly reduces the file itself Original 50MB PDF → content compression → 8MB (84% reduction) PDF is the most common file type that needs compression in office environments. Contracts, reports, presentations, electronic invoices — vast numbers of documents circulate as PDFs, and embedded high-resolution images, scanned pages, and vector graphics frequently cause file size bloat. A PDF file's size is primarily determined by: Embedded images and scans: A single 600DPI scanned page can reach 2-5MB; a 50-page document easily exceeds 100MB Embedded fonts: A complete CJK font set can occupy 10-20MB Vector graphics and redundant objects: CAD-exported vectors, replaced-but-not-deleted old images, hidden layers graph LR A[Input PDF] --> B[Image Resampling<br/>600DPI→150DPI] B --> C[Format Conversion<br/>FlateDecode→JPEG] C --> D[Font Subsetting<br/>keep used glyphs only] D --> E[Remove Redundant Objects<br/>clean unreferenced resources] E --> F[Linearization<br/>enable fast web view] F --> G[Output PDF<br/>80-90% size reduction] style A fill:#FFC107 style G fill:#4CAF50,color:#fff style B fill:#E3F2FD style C fill:#E3F2FD style D fill:#E3F2FD style E fill:#E3F2FD style F fill:#E3F2FD # PDF compression pseudocode def compress_pdf(input_pdf, target_dpi=150, jpeg_quality=72): # 1. Image resampling: 600DPI → 150DPI (~90% data reduction) for image in input_pdf.images: image.resample(target_dpi) # 2. Image format conversion: FlateDecode (PNG-like) → DCTDecode (JPEG) for image in input_pdf.images: image.convert_to_jpeg(quality=jpeg_quality) # 3. Font subsetting: keep only characters actually used in the document for font in input_pdf.fonts: font.subset(input_pdf.used_characters) # 4. Remove redundant objects: clean unreferenced resources, hidden layers, old versions input_pdf.remove_redundant_objects() # 5. Linearization (Fast Web View): restructure for streaming load input_pdf.linearize() return input_pdf.save() Real-world example: An 80MB scanned contract PDF (60 pages, 600DPI color scan), with a target of under 10MB for email: Image resampling: 600DPI → 150DPI Format conversion: FlateDecode → JPEG, quality 72% Font subsetting: enabled (scanned document includes OCR layer) Redundancy removal: clean duplicate objects and metadata from scanning Grayscale conversion: color pages converted to grayscale (contract text doesn't need color) Final result: 8.2MB, ~90% compression ratio, with text remaining clearly readable. graph TD subgraph Before P1[80MB Scanned Contract PDF] P1 --> P1a[60 pages, 600DPI color scan] P1 --> P1b[Full embedded CJK fonts] P1 --> P1c[Redundant scan objects] end subgraph After Q1[8.2MB Optimized PDF] Q1 --> Q1a[60 pages, 150DPI JPEG] Q1 --> Q1b[Subset fonts] Q1 --> Q1c[Redundant objects cleaned] end P1 -->|90% compression| Q1 style P1 fill:#FFC107 style Q1 fill:#4CAF50,color:#fff Images are the #1 culprit for file size bloat. A single smartphone photo can easily be 5-10MB, and a Word document with a dozen embedded images can quickly exceed 50MB. Format Compression Type Transparency Best For Characteristics JPEG Lossy No Photos, gradients High compression ratio, small size PNG Lossless Yes Icons, screenshots, transparent images Full detail preserved, larger size WebP Lossy/Lossless Yes Web images 25-35% smaller than JPEG TIFF Lossless/Uncompressed Yes Printing, pro photography Largest size, highest quality BMP Uncompressed No Rarely used Huge size, not recommended A simple rule of thumb: photos → JPEG, icons/screenshots → PNG, web images → WebP. Here's a more detailed decision flow: graph TD A[Choose Image Format] --> B{Need transparency?} B -->|Yes| C{Need lossless?} B -->|No| D{What's the use case?} C -->|Yes| E[PNG<br/>icons/screenshots/UI] C -->|No| F[WebP<br/>web transparent images] D -->|Photos/gradients| G{For web use?} D -->|Line art/text| H[PNG<br/>avoid JPEG artifacts] G -->|Yes| I[WebP<br/>smallest size] G -->|No| J[JPEG<br/>best compatibility] style E fill:#4CAF50,color:#fff style F fill:#2196F3,color:#fff style I fill:#2196F3,color:#fff style J fill:#FF9800,color:#fff style H fill:#4CAF50,color:#fff # Image compression key parameters from PIL import Image img = Image.open("photo.jpg") # Original 4000x3000, ~8MB # Resolution adjustment: halve → ~75% size reduction img_resized = img.resize((1920, 1080)) # Quality factor: 95→75, barely visible difference, ~50% size reduction img_resized.save("photo_compressed.jpg", quality=75) # Result: ~500KB, overall reduction ~94% graph LR A[Original Photo<br/>4000×3000<br/>~8MB] --> B[Resolution Adjusted<br/>1920×1080<br/>~2MB] B --> C[Quality Factor Adjusted<br/>Q95→Q75<br/>~500KB] A --> D[Total reduction: 94%] style A fill:#FFC107 style B fill:#FF9800,color:#fff style C fill:#4CAF50,color:#fff style D fill:#2196F3,color:#fff Resolution: Scaling 4000×3000 down to 1920×1080 reduces size by 75%+ Quality factor: Dropping JPEG quality from 95 to 75 is virtually indistinguishable to the human eye, yet cuts size by 50% Sweet spot: JPEG quality around 75 is sufficient for most use cases Video files are the largest of all file types. A 1-minute 4K video can exceed 400MB, and even a 1080p screen recording can be over 100MB. Codec Compression Efficiency Compatibility Encoding Speed Best For H.264 (AVC) Baseline Excellent (nearly all devices) Fast General use, email, mobile H.265 (HEVC) 40-50% smaller than H.264 Good (some older devices unsupported) Medium Storage archival, HD video VP9 Close to H.265 Good (primarily web) Medium Web video, YouTube AV1 20-30% smaller than H.265 Growing Slow Future standard, streaming graph LR subgraph Increasing Compression Efficiency H264[H.264<br/>Baseline 100%] --> H265[H.265<br/>saves 40-50%] H265 --> VP9[VP9<br/>~H.265 level] VP9 --> AV1[AV1<br/>saves 20-30% more] end subgraph Decreasing Compatibility C1[H.264: nearly all devices] --> C2[H.265: most devices] C2 --> C3[VP9: mainly web] C3 --> C4[AV1: emerging] end style H264 fill:#4CAF50,color:#fff style AV1 fill:#FF9800,color:#fff # FFmpeg video compression examples # Email: H.264 + 720p + CRF 28 (~5-10MB for 1 min) ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset medium \ -vf scale=1280:720 -r 30 -c:a aac -b:a 128k output_email.mp4 # Web publishing: H.264 + 1080p + CRF 26 ffmpeg -i input.mp4 -c:v libx264 -crf 26 -preset medium \ -vf scale=1920:1080 -r 30 -c:a aac -b:a 192k output_web.mp4 # Archival: H.265 + original resolution + CRF 20 ffmpeg -i input.mp4 -c:v libx265 -crf 20 -preset medium \ -c:a aac -b:a 192k output_archive.mp4 Three bitrate control modes compared: CRF (Constant Rate Factor): Quality stays constant, bitrate varies with scene complexity — most recommended CBR (Constant Bitrate): Bitrate stays fixed, suitable for live streaming VBR (Variable Bitrate): Dynamically adjusts within a specified range, ideal for precise target size control graph TD A[Video Bitrate Control] --> B[CRF - Constant Rate Factor] A --> C[CBR - Constant Bitrate] A --> D[VBR - Variable Bitrate] B --> B1[Constant quality] B --> B2[Bitrate varies with complexity] B --> B3[Best for: general compression] B --> B4[Typical range: 20-28] C --> C1[Fixed bitrate] C --> C2[Wastes bandwidth on simple scenes] C --> C3[Best for: live streaming] D --> D1[Bitrate fluctuates within range] D --> D2[Precise target size control] D --> D3[Best for: storage-constrained scenarios] style B fill:#4CAF50,color:#fff style C fill:#FF9800,color:#fff style D fill:#2196F3,color:#fff OFD (Open Fixed-layout Document) is a document format defined by the Chinese national standard GB/T 33190-2016, widely used in government agencies and public institutions for electronic official documents. International teams working with Chinese partners may encounter this format in cross-border business. Dimension OFD PDF Standard Chinese National Standard GB/T 33190-2016 ISO 32000 International Standard File structure XML + ZIP container, open structure Binary/text mixed, relatively closed Use cases Government docs, electronic certificates, bidding General documents, contracts, reports Signature support Native electronic seals, compliant with Chinese crypto standards Digital signatures supported, Chinese crypto needs adaptation An OFD file is essentially a ZIP archive containing XML files that describe pages, text, images, and other elements. Compression methods are similar to PDF: Image resampling: Reduce high-resolution images to appropriate resolution (300dpi → 150dpi) Font subsetting: Keep only the character glyphs actually used in the document Clean redundant objects: Remove unreferenced resources and duplicates Image format optimization: Convert uncompressed bitmaps to JPEG A 50MB OFD scanned government document can typically be compressed to 8-12MB with proper processing. graph TD A[OFD File Structure] --> B[ZIP Container Layer] A --> C[XML Description Layer] A --> D[Resource Layer] B --> B1[Doc_0/ document directory] B --> B2[Pages/ page directory] B --> B3[Res/ resource directory] C --> C1[Document.xml - doc description] C --> C2[Page_N.xml - page description] C --> C3[Signs/ - signature info] D --> D1[Image resources] D --> D2[Font resources] D --> D3[Color spaces] E[Compression Optimization] --> E1[Image resampling] E --> E2[Font subsetting] E --> E3[Remove unreferenced resources] E --> E4[Bitmap → JPEG] style A fill:#2196F3,color:#fff style E fill:#4CAF50,color:#fff graph LR subgraph Local Compression L1[User Device] --> L2[Local Compression Engine] L2 --> L3[Compressed File] L4[Files never leave the device] end subgraph Online Compression O1[User Device] -->|Upload file| O2[Third-party Server] O2 --> O3[Server-side compression] O3 -->|Download result| O4[User Device] O5[Files traverse network<br/>retention risk exists] end style L2 fill:#4CAF50,color:#fff style O2 fill:#FFC107 style L4 fill:#E8F5E9 style O5 fill:#FFF3E0 Dimension Local Compression Online Compression Data location Stays on local device Uploaded to third-party server Data transfer risk None Potential data exposure in transit Third-party risk None Leakage and retention risk Audit trail Enterprise can log processing Operations outside enterprise logging Network dependency None Required With regulations like GDPR (EU), CCPA (California), PIPL (China's Personal Information Protection Law), and HIPAA (US healthcare), organizations must consider: Data transfer risk: Using overseas online tools to process sensitive files may trigger regulatory reporting obligations Third-party processing risk: Even if providers promise deletion, transmission logs and backup mechanisms may leave traces Audit trail gaps: Many regulations require data processing logs to be retained for 6+ months — employees using personal online tools creates compliance blind spots Core principle: classify data, prioritize local processing, maintain audit trails. When evaluating compression tools, consider these dimensions: Dimension Key Question Format support Can it handle PDF, images, video, Office documents, and more? Compression ratio How effective is compression at equal quality? Are multiple compression levels available? Data security Does it require file upload? Local or cloud processing? Batch processing Can it compress multiple files simultaneously? Queue management? Platform support Windows, macOS, Linux? Apple Silicon support? Resource usage Does compression impact other applications? Is CPU/memory usage controllable? Cost What are the free tier limits? Is the paid pricing reasonable? It depends on the compression method. Lossless compression won't reduce quality, but lossy compression trades some detail for smaller size. Choosing the right compression level balances size and quality. Generally, compressing PDF to 150dpi is perfectly fine for screen reading — the difference is virtually imperceptible. 7-Zip is an archive compression tool that packages files into .7z/.zip archives — when extracted, the files are restored to their original size. Specialized content compression tools directly reduce the size of individual files (PDF, images, video) — the compressed file can be opened immediately without extraction. They serve different purposes: the former is for bundling, the latter for reducing individual file size. This typically happens with PDFs that are already highly compressed. If internal images are already low-resolution JPEG, re-encoding may introduce overhead. Prioritize redundant object removal and font subsetting — lossless operations that avoid re-encoding already compressed images. Yes. Local compression software can run entirely offline — files never touch the network. Open-source options like Ghostscript and PyMuPDF can perform local PDF compression via command line or programmatically, suitable for handling sensitive or classified documents. Commercial software typically offers friendlier interfaces and multi-format support. Generally, JPEG quality 75 is the sweet spot for balancing size and visual quality. Above 75, the human eye can barely tell the difference; below 75, noticeable blocky artifacts begin to appear. For extreme compression needs (like email attachments), 60 is acceptable; for high-quality preservation (like photography portfolios), 90+ is recommended. File compression isn't rocket science, but choosing the right method can save you enormous time and storage. The core principles: Know your goal: Email / web publishing / archival — different scenarios call for different parameters Choose the right approach: Lossy vs. lossless, archive vs. content compression Prioritize data security: Choose local compression for sensitive files to avoid compliance risks Quick reference table: File Type Recommended Parameters Expected Compression Scanned PDF 600DPI → 150DPI + JPEG Q72 80-90% Photos Halve resolution + JPEG Q75 75-94% Video for email H.264 + 720p + CRF 28 90-95% Video for web H.264 + 1080p + CRF 26 80-90% Video for archival H.265 + original resolution + CRF 20 50-70% OFD documents Image resampling + font subsetting 75-85% This is an original technical article. Feel free to share and repost with attribution.