If you’ve ever tried to upload a PDF and hit a file size limit, you’ve already seen why compression matters.

Most tools solve this by uploading your file to a server. That works, but it’s not always ideal, especially when dealing with private or sensitive documents.

The good news is that modern browsers are powerful enough to handle basic PDF compression locally.

In this tutorial, you’ll learn how to build a browser-based PDF compression tool using JavaScript, where everything runs directly in the browser.

Table of Contents

1. How PDF Compression Works

2. Project Setup

3. What Library Are We Using?

4. Creating the Upload Interface

5. Reading the PDF File

6. Understanding Compression Strategy

7. Compressing the PDF

8. Generating and Downloading the File

9. Demo: How the PDF Compression Tool Works

10. Important Notes from Real-World Use

11. Common Mistakes to Avoid

12. Conclusion

How PDF Compression Works

PDF compression is different from image compression.

A PDF isn't just a single image. It’s a structured document that can include text, images, fonts, and metadata. Because of this, reducing its size involves optimizing multiple parts of the file rather than applying a single compression method.

In most cases, compressing a PDF means lowering image quality where possible, removing unnecessary or unused data, and optimizing how the document is internally structured.

When working in the browser, we don’t have the same level of control as server-side tools. But we can still reduce file size by reprocessing the document and saving it in a more efficient format.

This approach may not achieve extreme compression, but it works well for creating lighter, more efficient files while keeping everything fast and private.

Project Setup

This project is simple.

You only need:

• an HTML file

• JavaScript

• a PDF library

No backend is required. Everything runs locally in the browser.

What Library Are We Using?

We’ll use pdf-lib, which allows us to load and recreate PDF files.

Add it using a CDN:

<script src="https://unpkg.com/pdf-lib/dist/pdf-lib.min.js"></script>

Creating the Upload Interface

Start with a simple interface:

<input type="file" id="upload" accept="application/pdf">
<button onclick="compressPDF()">Compress PDF</button>

<a id="download" style="display:none;">Download Compressed PDF</a>

This allows users to upload a PDF, trigger compression, and download the result once ready.

Reading the PDF File

Now read the uploaded file:

const fileInput = document.getElementById("upload");

if (!fileInput.files.length) {
  alert("Please upload a PDF");
  return;
}

const file = fileInput.files[0];
const arrayBuffer = await file.arrayBuffer();

Understanding Compression Strategy

Since we’re working in the browser, we don’t have full low-level control over PDF compression.

Instead, we focus on practical optimizations that help reduce file size without affecting usability too much. This includes recreating the document structure in a more efficient way, removing unnecessary metadata, and reducing image quality where possible.

The goal here isn’t perfect compression, but producing a lighter file while maintaining acceptable visual quality and readability.

Compressing the PDF

Here’s the core logic:

async function compressPDF() {
  const fileInput = document.getElementById("upload");

  if (!fileInput.files.length) {
    alert("Please upload a PDF");
    return;
  }

  const file = fileInput.files[0];
  const arrayBuffer = await file.arrayBuffer();

  const { PDFDocument } = PDFLib;

  const originalPdf = await PDFDocument.load(arrayBuffer);
  const newPdf = await PDFDocument.create();

  const pages = await newPdf.copyPages(
    originalPdf,
    originalPdf.getPageIndices()
  );

  pages.forEach(page => newPdf.addPage(page));

  const pdfBytes = await newPdf.save({
    useObjectStreams: true
  });

  const blob = new Blob([pdfBytes], { type: "application/pdf" });

  const link = document.getElementById("download");
  link.href = URL.createObjectURL(blob);
  link.download = "compressed.pdf";
  link.style.display = "inline";
  link.innerText = "Download Compressed PDF";
}

This recreates the PDF using optimized object streams, which can reduce file size.

Generating and Downloading the File

Once processed:

link.href = URL.createObjectURL(blob);
link.download = "compressed.pdf";

The file is downloaded instantly, without any server interaction.

Demo: How the PDF Compression Tool Works

Here’s how the full flow looks in a real-world scenario using the browser-based PDF compression tool.

Step 1: Upload PDF

Start by uploading your PDF file. You can either drag and drop the file into the upload area or click the “Select PDF” button to choose a file from your device.

Step 2: Preview the PDF

Once the file is loaded, the tool displays a preview of the document. You can navigate between pages to confirm that the correct file has been uploaded before applying compression.

Step 3: Choose Compression Settings

Next, select the compression level based on your needs. Lower compression keeps better quality, while higher compression reduces file size more aggressively. You can also explore advanced options like metadata handling.

Step 4: Compress the PDF

Click the “Compress PDF” button to start the process. The tool processes everything directly in your browser, without uploading files to any server.

Step 5: Download the Compressed File

After compression is complete, you’ll see the final result along with the reduced file size. You can then rename and download the optimized PDF instantly.

Important Notes from Real-World Use

When working with PDF compression in the browser, handling large files becomes important.

If a user uploads a very large PDF, processing everything at once can slow down the browser or even cause it to freeze. Instead of trying to process everything blindly, it’s better to add checks and handle files carefully.

For example, you can limit the file size before processing:

const MAX_SIZE = 10 * 1024 * 1024; // 10MB

if (file.size > MAX_SIZE) {
  alert("File is too large. Please upload a file under 10MB.");
  return;
}

This prevents performance issues and keeps the tool responsive.

Another useful approach is to process files step by step instead of doing everything at once:

const { PDFDocument } = PDFLib;

const originalPdf = await PDFDocument.load(arrayBuffer);
const newPdf = await PDFDocument.create();

for (let i = 0; i < originalPdf.getPageCount(); i++) {
  const [page] = await newPdf.copyPages(originalPdf, [i]);
  newPdf.addPage(page);
}

This spreads the work across smaller steps and avoids blocking the browser.

It’s also important to remember that everything runs client-side. This means files never leave the user’s device, which is great for privacy. But it also means performance depends on the user’s device, so keeping processing efficient is important.

Common Mistakes to Avoid

One common mistake is not validating user input properly before processing the file.

For example, users might try to upload an empty file, a non-PDF file, or even trigger the compression without selecting anything. It’s important to check these cases early to avoid errors later in the process:

const fileInput = document.getElementById("upload");

if (!fileInput.files.length) {
  alert("Please upload a PDF file.");
  return;
}

const file = fileInput.files[0];

if (file.type !== "application/pdf") {
  alert("Only PDF files are supported.");
  return;
}

Another issue is allowing invalid or unexpected input to pass through. Even something as simple as an empty or corrupted file can cause the PDF processing to fail, so basic validation makes the tool much more reliable.

Handling large files without any checks is another common problem. If a very large PDF is processed without limits, it can slow down the browser or even make the page unresponsive. Adding a simple file size check helps prevent this:

const MAX_SIZE = 10 * 1024 * 1024; // 10MB

if (file.size > MAX_SIZE) {
  alert("File is too large. Please upload a file under 10MB.");
  return;
}

Another mistake is assuming that compression will always produce a significantly smaller file. In reality, browser-based compression is limited compared to dedicated server-side tools, so results can vary depending on the content of the PDF.

In practice, most issues come from missing validation and handling edge cases. Adding a few simple checks early makes the tool more stable and improves the overall user experience.

Conclusion

In this tutorial, you built a browser-based PDF compression tool using JavaScript.

You learned how to read and recreate PDF files, apply basic optimizations, and generate a downloadable file entirely in the browser.

If you’d like to try a complete version of this idea, you can check it out here: https://allinonetools.net/pdf-compressor/

This approach keeps everything fast, private, and simple to use.

Once you understand this pattern, you can extend it further to build more advanced document tools.

And that’s where things start getting really interesting.

Recently, I have faced an issue where I needed to compress a lot of files individually, and manual intervention to compress each file one by one using traditional 7zip became a hassle.

If you are in love with the Windows operating system like I am (I know, I know, sometimes Windows can become quite a pain. Maybe I like the pain and also like to resolve issues all by myself, who knows!), then you may also face issues in batch processing compressing multiple files to the .gzip format.

There are multiple ways to compress a file into the .gzip format. The main issue is that most of the ways do not support batch processing the conversion. In this article, I will talk about two of the decent ways you can do this.

Method 1: Using 7zip (No Batch Processing)

7zip is a free software available for Windows, Linux, and ARM64. Installing 7zip in the Windows operating system is very simple and straightforward.

If you simply want to compress any single file to .gzip format, you need to simply select that file and add it to the 7zip archive. In the GUI, you can select the Archive format as "gzip" and that's it!

gzip in 7zip

Method 2: Using gzip from Chocolatey (Batch Processing is the Main Benefit of This)

There are several tools that we can use to compress files and folders on our computers. However, Linux-based operating systems come with a lot of tools and there are a lot of CLI (Command Line Interface) type tools that we can also use to compress multiple files altogether in a batch.

If you use Linux based operating system, then you might have also used GZip. Gzip is a file format and software application that compresses and decompresses files. It also makes files smaller and allows for faster network transfers. However, there are not any official installers of GZip for the Windows operating system.

But, we can install "gzip" directly on Windows and work like we're in a Linux OS. I prefer to download GZip via Chocolatey, a very good package manager for the Windows operating system.

Chocolatey is a machine-level, command-line package manager and installer for software on Microsoft Windows. It uses the NuGet packaging infrastructure and Windows PowerShell to simplify the process of downloading and installing software.

If you are using Chocolatey for the first time, then you need to install it first. All of the methods are explained in detail on their official website: https://chocolatey.org/install.

Chocolatey Installation

Open your Terminal and run the command for installing "gzip".

choco install gzip

Write "Yes" when it asks for your permission. After a few seconds, you should be ready to use it.

Let's say I want to batch-compress a lot of files into ".gzip". I can open my terminal and go to that directory (where my raw files are that I want to compress using gzip) using the cd path/to/where/I/have/the/files command.

Or, I can simply open my terminal directly using the "Open In Terminal" context menu in that specific directory where I have the files that I want to compress using gzip. Then I can simply use the following command.

gzip * -r

This will iterate through every folder and subfolder in that specific location and compress all of the files to .gzip recursively (the -r flag). Keep in mind that it will replace all your files to .gzip in that directory.

But, if you also want to keep the original files side by side during the batch compression process, you can use the command below.

gzip * -r -k

Here, the -k flag indicates the --keep option to keep the original files.

If you want to use all your CPU cores in parallel, then follow the command below.

parallel gzip ::: *

You have to add the necessary suffixes to suit your needs obviously in this process.

That's it!

Conclusion

I hope you have gained some valuable insights from this article.

If you have enjoyed the procedures step-by-step, then don't forget to let me know on Twitter/X or LinkedIn. I would appreciate it if you could endorse me for some relevant skillsets of mine on LinkedIn.

You can follow me on GitHub as well if you are interested in open source. Make sure to check my website (https://fahimbinamin.com/) as well.

Thank you so much!

Minification is the process of reducing code size to reduce the size of your files. So how does this apply to CSS?

Take a look at this code:

h1 {
  color: yellow;
}

p {
  color: pink;
}

And the compressed version of it:

h1 { color: yellow; } p { color: pink; }

These two code blocks are the same thing, and they work the same way because they have the correct CSS syntax. But there are two differences between these code blocks:

• the first one is more readable and understandable compared to the second one with a one-liner
• the first one results in bigger file size compared to the second one.

On testing this on my computer, the first one has a size of 46 bytes while the second is 40 bytes. This difference may seem insignificant, but it becomes noticable when you consider the difference that a compressed version of a bigger codebase can make.

Why does the compressed size matter?

When a browser gets an HTML document from a server, it fetches the resources linked in the document. These resources include images, scripts, and also stylesheets.

The larger a CSS file is, the more resources (such as network bandwidth) it takes to download. Also, the longer it takes to download such files. This results in slower page load times and affects the overall user experience.

These expenses can be ignored for small CSS files, but as a program grows, compression becomes an essential factor in improving page load times.

All the browser needs is valid CSS, not readable or formatted CSS

Compressed file sizes do not affect how the browser parses CSS. The browser does not need readable CSS to be able to interpret it on a web page. It only needs valid CSS (CSS code with a correct syntax – curly braces, semi-colons, and so on).

Therefore, the extra spaces, comments, and indentations do not matter to the browser. It only matters for development.

For deployed applications, you need a distributable version of CSS.

The distributable version isn't meant to be read by humans or used during development – but rather it's used for deployed applications as they only matter to the browser.

How does minified CSS work?

The goal of minification is to remove the parts of your CSS code that are irrelevant to the browser to interpret the CSS.

For example, this code:

h1 {
  /* a header */
  color: yellow;
}

Here's a graphical presentation of the parts of the code that matter and those that do not:

Code comments can help developers work together, remember why decisions are made, and understand the purpose of different parts of code. But the browser does not need that information.

Spaces and indentation improve the readability of code by humans, but the browser can read code without spaces.

The element selector, curly braces, and semi-colon are essential parts of the code as they follow the CSS syntax and help the browser interpret the code correctly.

CSS minification methods take these parts that the browser does not need from the code, which result in a lower-sized file, and makes it faster for the browser to download such files from the server.

The minified version of the above code is:

h1{color:yellow;}

And everything still works perfectly on the browser.

How to minify CSS

Now you understand the relevance of compressed CSS files and how they work. So how do you minify your CSS files?

Of course, you cannot write minified CSS code during development because it makes code collaboration, reading, and understanding difficult.

Here are some tools you can use to minify your CSS.

clean-css

clean-css is an NPM library you can use to minify your CSS files either locally or from a remote server.

Dan's Tools CSS Minifier

Dan's Tools Minifier is an online CSS minification tool for minifying CSS. You can paste the CSS in an input field, enter a URL where the CSS file lives, or paste the CSS file.

Screenshot from the Dan's Tools CSS Minifier page

Toptal CSS Minifier

Toptal CSS Minifier provides a UI to add your CSS, and see the minified output. It also provides an API and plugins that makes the process automated.

Toptal CSS Minifier screenshot

There are more tools and configurations you can apply to make the process easier – these are just a few.

Wrap up

Minification, generally, is a great approach for optimizing websites. Minifying CSS files increases page load times and requires fewer resources by the browser to download.

During development, comments, indentation, and other forms of formatting improve code readability and collaboration. But the browser does not need that.

CSS minification is the process of compressing CSS file sizes by taking out the irrelevant part of the files that the browser does not need to interpret on a webpage.

Fortunately, some tools make it easier, so you can enjoy the process of development and also get a distributed version at the end.

You can also compress older and rarely used files and save them for future use which helps you conserve disk space.

In this post, we'll look at how to compress files with the tar command in Linux, along with some examples of tar in action.

What is the tar command?

We use the tar command to compress and expand files from the command line. The syntax is shown below:

tar [flags] destinationFileName sourceFileName

The tar command uses the following flags to customize the command input:

How to create an archive

We have a list of the following files which we'll compress with tar.

List of files to be compressed.

To compress them, we'll use tar like this:

tar -czvf logs_archive.tar.gz *

Let's break down this command and look into each flag.

-c is creating and archive.

-z is using gzip compression.

-v is providing details of the files that have been archived.

-f is creating an archive with the name 'logs_archive.tar.gz' as supplied in the command above.

In the results below, we can see that the archive has been created successfully.

Archive has been created with supplied command.

How to remove files after compression

Let's say we don't want to keep the original files after creating an archive. For that, we can use the --remove-files flag.

tar -czvf logs_archive.tar.gz * --remove-files

Files removed once archive has been created

Here, the -czvf flags are working as demonstrated before, but the original files are also removed. Once we list the files, we only see the archive.

How to view the contents of an archive

You might need to view the contents of an archive without actually extracting it. You can do this with the -t flag.

tar -tvf logs_archive.tar.gz

In this command, -t flag specifies that we need to only view the contents of the archive. -f specifies the filename and -v displays the detailed contents.

Viewing contents of an archive.

How to extract an archive

To extract files from an archive, you use the -x flag like this:

tar -xzvf logs_archive.tar.gz

Let's break down this command and look into each flag.

-x is extracting and archive.

-z specifies that the archive is gzip.

-v is providing details of the files that have been archived.

-f is extracting from the archive named 'logs_archive.tar.gz'.

Extracting an archive.

Here's a useful tip: commands that take a long time to execute can continue in the background with &.

Adding files to an archive and extracting an archive can take a while. To keep the commands running in the background while you keep working, pair the command with & like this:

tar -xzvf logs_archive.tar.gz &

How to search in compressed log files

You might still need to access certain files once they're archived. Luckily, there is a method you can use to search and view compressed log files without decompressing them and compromising disk space.

The command you can use to search in compressed files is zgrep:

Contents of a file 'audit.log' in an archive.

We can search for a string in an archive using the below command:

 zgrep -Hna 'string-to-search' compressedFile.tar.gz

Let's briefly look at the flags.

-H lists the file name that contains the match.

-n displays the line number that contains the matched string.

-a treats all files as text files.

This is the result:

Wrapping Up

File compression helps us save time and resources when sharing files. Servers are almost always rotating and archiving huge log files.

You can also schedule file compression via cron jobs to automate disk cleaning. I highly recommend that you take advantage of this utility.

Thanks for reading until the end. I would love to connect with you. You can find me here on Twitter. Do share your thoughts.

See you around.

Great question Dion! I will answer it, and not just because you’re my new boss, but because it’s a good question. (but also because you’re my new boss.)

I want to set something clear here though : we’re not really comparing Apples-to-Apples, so let’s define some technologies first.

How Mario Works

So let’s talk about how the original Super Mario game worked, from an asset perspective.

The original NES console was only designed to output images that were 256 wide by 240 high; meaning that the final image that needed to be displayed to the screen was 180kb in size.

Besides that, the NES only had 2kb of RAM. A cartridge itself could could hold 8k to 1mb of game data. So, there was no way to fit the entire game’s contents into main memory. Basically, a subset of the 1MB cartridge data must be loaded into the 2kb RAM and used to render the 180kb screen. How does one achieve that?

SpriteSheets.

Sprite sheets contain small tiles of graphics, that are re-used over and over again. For example, below is a remake of the original super mario sprite sheet:

It’s not the exact original sprite sheet, but you can get a sense of the small blocks of data that can be use over-and-over again.

Each small 16x16 pixel square represents a “tile” and artists would string these together to create the actual levels. The levels themselves, just became a giant 2D array of indexes into the sprite sheet. (I talk about this in a lot more detail in Lesson 3 of my HTML5 Game Development course @ Udacity, or in my book HTML5 Game Development Insights.) Tack on some Run-Length-Encoding, or some basic LZ77, and you get a fairly compact format for levels.

Behold, that level that you parents could never complete.

So with concepts like tile-sheets and sprite-sheets, we can use a small set of images to create large scenes & worlds. This is generally how most games work. Even 3D games will have a set of common textures that are applied multiple times and places throughout the game itself.

Now let’s talk about generic image compression.

How Images are compressed

Here’s the “not fair” part of this comparison. Generic image compression algorithms have no domain knowledge about the pixels inside of them. JPG, PNG, WebP have all been designed for photos and not so much game screens. The result is that for a given 16x16 pixel block, these algorithms assume it’s unique among the image; Besides some color quantization, there’s no real logic added to determine if another 16x16 block could be an exact duplicate of the current one. This generally means there’s a lower-bound on how a given block of data is compressed.

For example, JPG breaks a given image into 8x8 pixel blocks, converts the RGB color space into the YCbCr version, and then applies Discrete cosine transform on them. It’s only after this step, does a lossless encoder come along, and see if it can match up common duplicate groups using DPCM, or RLE.

A block-view of how JPG image compression works.

So, the only place where two blocks might get compacted into 1 block, is if their post-DCTd version is identical, and RLE can make stride recommendations. This doesn’t happen that often.

Despite its other flaws, PNG is much better in this regard. PNG compression is entirely lossless, (so your image quality is high, but your compression savings are low), and based on the DEFLATE codec, which pairs LZSS along with Arithmetic Compression. The result is that long runs of similar pixels can end up being cut down to a much smaller size. This is why an image with a very uniform background will always be smaller as a PNG instead of a JPG.

The below image is a 5.9kb PNG file, while the JPG image is 106kb

Since this image has lots of duplicate pixels (the blue sky background) compressors like PNG do a better job than their block-based JPG counterparts.

Apples vs. Dragonfruit

My point here is that it’s kinda unfair to compare game content to a single image on the internet.

From the game side, you start with a small set of re-usable tiles, and index them to build up your larger image, we can do this, because we know how the game is going to be made. On the other side, JPG/PNG/WebP just tries to compress the data it can find in local blocks, without any real desire to match repeated content. Image compression is clearly at a disadvantage here, since they don’t have prior knowledge of their data space, they can’t really make any expectations about it.

I mean, consider The Demo Scene which is super big on this sort of thing. They can cram 30minutes of an entire 3d shooter into 64kb because they understand and know so much more about their data.

_A much better comparison. The .[kkrieger](https://en.wikipedia.org/wiki/.kkrieger" rel="noopener" target="blank" title=") demo fit 30 minutes of a 3D shooter gameplay, with physics, sound, textures, and AI into 64kb of data. Seems like a massive amount of gain for just 24kb more than the original Mario.

It just goes to show, with the right amount of foreknowledge about your data, you can do great things with compression.

Looking forward.

Obviously, we’ve grown up since the 256x240 displays of the NES days. The phone in my pocket has 1,920 x 1,080 display pixels @ it’s 5.2” size, giving it ~423 pixels per inch density. To compare that in the same number of pixels that’s ~33 super-mario screens, or rather, 8MB of pixel data. I don’t think anyone’s surprised that screen resolutions are increasing, but it also comes with the need for more data.

This is something I’ve been harping on for a while now. While we get bigger displays, the content channels need to up their resolution outputs in order to still look good on our higher-density setups (otherwise, we get scaling blurryness..). This of course, causes our video game packages to grow in size, our web-pages to grow in size, and even our youtube streaming videos to grow in size. Basically, we’re sending more data to smaller devices simply due to screen resolution. Which, for the next 2 billion folks in emerging markets, on 2G connections, is like the worst idea ever.

But I digress. That’s a different post.