DEV Community: Chris Howe

Why PDF Size Should Be Checked Before It Breaks Your Workflow

Chris Howe — Wed, 14 Oct 2026 09:10:06 +0000

A document workflow often looks simple:

Create a document → Export as PDF → Upload or send it.

But in many real-world scenarios, the final step is where problems appear.

A report is finished. A contract has been reviewed. A presentation has been exported.

Then someone tries to upload it and gets an error:

“File size exceeds the limit.”

At this point, the document itself is already complete. The problem is not the content, but the way the file needs to move through different systems.

This is why PDF file size management should be considered part of the document workflow, not something to solve at the very end.

PDF size problems usually appear too late

Most people don't think about file size while creating documents.

When writing a report, adding images, or scanning pages, the priority is usually content quality.

A high-resolution image makes a presentation look better.

A scanned document keeps more details.

A complete report contains all necessary information.

But all these choices increase the final PDF size.

The issue is that many platforms have strict upload limits:

Email services limit attachment sizes.
Online forms reject oversized documents.
Collaboration platforms may slow down when processing large files.
Cloud uploads take longer with bigger files.

The workflow usually fails after the important work has already been completed.

A better approach: treat PDF size as a workflow checkpoint

In software development, many teams use validation steps before deployment.

Code is tested before release.

Data is checked before entering production.

Files can follow a similar approach.

Instead of waiting until the final upload fails, PDF size can become an early checkpoint:

Create the document.
Export it as PDF.
Check the file size.
Compress if necessary.
Continue sharing or uploading.

This simple step can prevent unnecessary interruptions.

Why PDF compression is often the easiest solution

Manually reducing PDF size can be complicated.

Users may need to:

adjust image quality;
remove unnecessary elements;
export the document again;
compare different versions.

For occasional users, this process takes too much time.

A PDF compression tool simplifies the workflow by handling file optimization automatically.

For example, PDFCompress is a free online PDF compressor designed for users who need to reduce PDF file size quickly without installing additional software.

The process is straightforward:

Upload a PDF file → compress the document → download the optimized version.

This makes it easier to prepare documents for email attachments, online submissions, and file sharing.

File optimization is not only about smaller files

When people think about compression, they often focus only on reducing size.

But in practice, the bigger goal is improving document usability.

A smaller PDF means:

faster uploads;
easier sharing;
fewer platform restrictions;
smoother collaboration.

The best optimization is not simply making a file smaller.

It is making the file easier to use in the environment where it needs to work.

Small workflow improvements create better experiences

Modern digital workflows are built from many small steps.

A document is created.

A file is exported.

A platform processes it.

A user downloads or shares it.

Any single step can become a bottleneck.

PDF size is one of those problems that seems minor until it blocks the entire process.

By adding file size checks and compression into the workflow, teams and individuals can avoid unnecessary delays.

Tools like PDFCompress represent a simple idea:

Good productivity tools do not always automate the biggest tasks.

Sometimes, they remove the small obstacles that interrupt important work.

Build a PDF Size Gate Before Your Document Pipeline Hits “Send”

Chris Howe — Tue, 13 Oct 2026 10:19:13 +0000

The report rendered perfectly. The upload failed anyway.

The bug was not in the report

A successful build with an unusable artifact

The job had done everything we asked of it. It queried the database, rendered charts, assembled a 126-page PDF, uploaded the artifact to storage, and marked the run green. Ten minutes later, someone tried to attach the report to a client portal and got a wonderfully unhelpful message: “File exceeds maximum size.”

The PDF was 38.7 MB. The portal allowed 20 MB.

Nothing in our pipeline considered that a failure because we had defined success too narrowly. We tested whether the file existed and whether it could be opened. We did not test whether it could complete the next step in the user’s workflow. The document was technically valid and operationally useless.

That incident changed the way I think about generated PDFs. A PDF is not finished when the renderer exits with code zero. It is finished when the intended destination accepts it and the reader can still use it. File size belongs in the acceptance criteria, just like page count, content checks, and render quality.

Treat size as an interface contract

Most document pipelines have an implicit interface at the end. It might be an email gateway, a grant application, a learning management system, a support ticket, or a customer portal. That interface has constraints even when your report generator does not know about them.

The simplest improvement is to make the size budget explicit. Instead of generating a PDF and hoping for the best, define a delivery profile with a maximum number of bytes and a small safety margin. The margin matters because platforms do not always describe units consistently, and some wrap attachments with additional metadata.

A 20 MB destination should not produce a 19.99 MB target. I would rather set the internal budget to 18 MB and leave room for disagreement about decimal megabytes, binary mebibytes, or a portal’s own processing overhead. This is not glamorous engineering, but neither is reopening a release five minutes before a deadline.

Keep the master separate from the delivery copy

Compression should create a derivative artifact. It should not overwrite the source PDF.

The master is the closest representation of what the renderer produced. It is useful for archival, future exports, and debugging. The delivery copy is optimized for one channel with one size budget. If requirements change, you should be able to create a new delivery copy from the master instead of compressing an already compressed file again.

Repeated compression is especially risky for image-heavy documents. Every generation may introduce another round of downsampling or lossy encoding. The file keeps getting smaller, but the relationship between size and visible quality becomes harder to reason about. A clean master gives the pipeline a stable starting point.

Add a small gate before adding a big system

Measure bytes, not a formatted string

The first version of a size gate can be deliberately boring. In Node.js, the filesystem already gives us the exact byte count. We can compare it with a configured budget and return a structured result that the rest of the pipeline can understand.

import { stat } from "node:fs/promises";

const MiB = 1024 * 1024;

export async function checkPdfBudget(path, budgetMiB) {
  const file = await stat(path);
  const limitBytes = budgetMiB * MiB;

  return {
    path,
    bytes: file.size,
    sizeMiB: Number((file.size / MiB).toFixed(2)),
    budgetMiB,
    withinBudget: file.size <= limitBytes,
    excessBytes: Math.max(0, file.size - limitBytes),
  };
}

This function avoids making presentation strings part of the decision. The comparison happens in bytes; sizeMiB exists only for logs and human-readable reports. That distinction prevents a rounded value such as 20.00 MB from hiding the fact that the file is a few kilobytes over the real threshold.

The gate should run immediately after rendering and before distribution. If the file fits, the pipeline can continue. If it does not, the result should enter a compression path or stop with an actionable message. “Generated successfully” is not actionable. “Generated 38.7 MiB; delivery budget is 18 MiB” is.

Make the result visible in CI

A command-line wrapper turns the check into something CI can enforce. The script can print machine-readable JSON and use the process exit code to express the outcome.

#!/usr/bin/env node
import { checkPdfBudget } from "./pdf-budget.js";

const [, , path, budget = "18"] = process.argv;

if (!path) {
  console.error("Usage: node check-pdf.js <file.pdf> [budgetMiB]");
  process.exit(2);
}

const result = await checkPdfBudget(path, Number(budget));
console.log(JSON.stringify(result, null, 2));

if (!result.withinBudget) {
  process.exitCode = 1;
}

Now the document build has a clear boundary. A scheduled report can fail before anyone emails it. A pull request that changes charts or embedded assets can reveal a size regression. A local developer can run the same command that CI runs. That consistency is more valuable than a sophisticated dashboard nobody trusts.

Do not confuse a size regression with a rendering failure

The gate should classify the problem accurately. A PDF that is too large is not corrupt, and a PDF that is corrupt is not merely oversized. Keeping these outcomes separate makes retries and alerts much more useful.

For example, a renderer failure may require inspecting HTML, fonts, or browser logs. A budget failure may indicate that a new image was embedded at full camera resolution, a font subset stopped working, or a chart library started rasterizing at a larger scale. The artifact exists in both cases, but the investigation path is different.

Understand what made the PDF heavy

A PDF is a container, not a screenshot

It is tempting to describe PDF compression as turning down a single quality knob. In reality, a PDF may contain text streams, embedded fonts, vector paths, raster images, forms, metadata, and duplicated resources. Scanned documents are often dominated by page-sized images. A generated financial report may contain searchable text and vector charts but still carry several large logos or screenshots.

That structure affects what compression can achieve. Recompressing images can produce a dramatic reduction in a scanned brochure. The same operation may barely change a mostly textual report. Aggressively rasterizing every page can shrink some files, but it may also remove searchable text and make small type less readable. A smaller byte count is not automatically an optimization.

Before choosing a response, I like to gather a few cheap signals with Poppler tools:

pdfinfo build/report-master.pdf
pdffonts build/report-master.pdf
pdftotext build/report-master.pdf - | tr -d '[:space:]' | wc -m
pdfimages -list build/report-master.pdf | sed -n '1,20p'

pdfinfo gives the page count and basic metadata. pdffonts tells us whether fonts are embedded. pdftotext provides a rough signal for a usable text layer. pdfimages -list helps reveal large raster assets. None of these commands is a perfect classifier by itself, but together they narrow the problem quickly.

Sample the pages that are most likely to fail

A document can be mixed. The first fifty pages may be clean text, followed by a scanned appendix. Checking only the cover creates false confidence. A useful validation set should include a normal text page, a chart-heavy page, a table with small type, a photo-heavy page, and at least one appendix page when those layouts exist.

This is one place where a short manifest helps. The report generator already knows which templates created which sections, so it can emit representative page numbers alongside the PDF. If that is not possible, the team can maintain a small set of known-risk pages in the delivery profile.

The goal is not pixel-perfect visual testing of every page. The goal is to make quality checks intentional. Randomly opening page one after compression is not a test plan; it is a ritual.

Choose the compression path deliberately

Automate the stable path, keep an escape hatch

If your application produces the same document type every day, automated compression can make sense. You can run a known tool with versioned parameters, generate a candidate, validate it, and retain the original if the candidate is larger or fails checks. The compression policy becomes code and can evolve with the template.

Not every team needs that system on day one. Some PDFs are created manually, some failures are rare, and some deadlines arrive before a new service can pass review. In those cases, a browser workflow is a reasonable operational escape hatch, provided the output still goes through the same quality gate.

For an occasional oversized delivery, I use PDFCompress to create the derivative copy. It accepts PDFs directly in the browser, offers high, medium, and low compression modes, supports files up to 1 GB, and can process as many as five files in one batch. The result is available for immediate download without a watermark. That makes it useful when a teammate is on a locked-down machine or even a phone, but it does not remove the need to record the selected mode and validate the result.

The important design decision is not “online tool versus command line.” It is whether the workflow has a source artifact, a named compression policy, and a testable candidate. A manual step can be disciplined. An automated step can still be careless.

Start with the least destructive mode that meets the budget

When compression offers several levels, begin with the option that preserves the most quality. If the output fits the delivery budget, stop. If it does not, move to the next level and compare again. This sounds slower than selecting the strongest setting immediately, but it often avoids unnecessary damage and gives the team evidence about the document’s real compression headroom.

Store the result of each attempt as data, not folklore. Record input bytes, output bytes, selected mode, duration, page count, and validation status. Over time, the pipeline will reveal patterns. Perhaps the marketing report nearly always passes on a medium setting, while scanned field reports need stronger compression. Those patterns can later justify automation.

Reject a candidate that does not improve the artifact

Compression is not guaranteed to help every file. A PDF may already contain optimized images and compressed object streams. Processing it again can produce almost no saving, or occasionally a larger output. The pipeline should compare candidates and refuse to replace the delivery copy when there is no meaningful benefit.

A simple savings calculation is enough:

export function compressionSummary(inputBytes, outputBytes) {
  const savedBytes = inputBytes - outputBytes;
  const savedPercent = inputBytes === 0
    ? 0
    : (savedBytes / inputBytes) * 100;

  return {
    inputBytes,
    outputBytes,
    savedBytes,
    savedPercent: Number(savedPercent.toFixed(1)),
    improved: outputBytes < inputBytes,
  };
}

This protects against a surprisingly common workflow bug: naming the latest output compressed.pdf and assuming that the name proves the result.

Validate the delivery copy, not just the process

Compare invariants before looking at pixels

The first checks are structural. The output should open, retain the expected page count, and remain under the configured byte budget. If the workflow depends on text search or copy and paste, text extraction should still return plausible content. Links, bookmarks, and forms should be tested when they matter to the destination.

These are not universal requirements. A scanned handout may never have had selectable text. A print-only brochure may not need internal links. Validation should reflect the artifact’s actual contract, which is why a delivery profile is more useful than one global “PDF passed” flag.

Render representative pages for visual review

Structural tests cannot tell you whether a chart label turned muddy or a thin grid line disappeared. Render the known-risk pages to images and compare them at a consistent resolution. The first version of this check can be manual; the important part is that reviewers look at the same pages every time.

mkdir -p build/preview

pdftoppm \
  -f 8 -l 8 \
  -r 144 \
  -png \
  build/report-delivery.pdf \
  build/preview/page

Automated image diffs can come later, but they need sensible thresholds. Compression changes pixels by design, so a strict byte-for-byte image comparison will produce noise. Start by checking legibility, missing content, unexpected rotation, color banding, and obvious blocking around small text.

Test the real destination once

The final integration test is the one we skipped in the opening story: submit the file to the actual destination. Local size checks cannot discover every portal rule. The receiver may impose its own filename restrictions, MIME checks, timeouts, or preview conversion.

For recurring pipelines, this may be a staging endpoint or a documented manual release check rather than an automated production upload. Either way, the destination should appear in the definition of done. A green renderer and a green compression job are still intermediate states.

The gate changes team behavior

Fail early with a useful explanation

Once the size budget became visible in our pipeline, the conversation changed. Instead of discovering the problem at the upload screen, we saw which build introduced the regression. Instead of asking someone to “make it smaller,” we could say how far over budget it was and which pages or assets had changed.

That is the real benefit of a PDF size gate. It turns a last-minute human surprise into an observable property of the artifact. Compression remains a tradeoff, but it becomes a tradeoff the team can measure, review, and repeat.

The implementation can begin with a dozen lines of Node.js and a written validation routine. Add automation only when the document volume and failure rate justify it. Whatever tools you choose, preserve the master, generate a delivery copy, and test the copy against the channel it is meant to cross.

A PDF pipeline should not celebrate merely because it produced a PDF. It should celebrate when the document arrives, opens, and still says what it was meant to say.

I Built a Free Online Video Compressor in 2 Weeks

Chris Howe — Fri, 10 Oct 2025 04:12:12 +0000

Hi everyone!
Over the past two weeks, I built a small side project called VideoCompress
— a fast, free, and easy-to-use online video compressor with no watermark or usage limits.

💡 The Problem

There are plenty of “free” online video compressors, but most of them come with frustrating limitations — watermarks, file size limits, or hidden paywalls.
I wanted something simple: just upload → compress → download — no distractions, no tricks.

🧱 The Tech Stack
The project is built with:

Frontend: Nuxt, for static site generation and an ultra-fast UI.
Backend: FastAPI, for handling API requests.
Video Processing: FFmpeg, running on the server for efficient compression.

The Nuxt app is completely static — deployed on a CDN for fast global access — while the backend API handles the heavy lifting on the server.

⚙️ Why I Moved Compression to the Backend

Initially, I implemented compression on the frontend using WebAssembly builds of FFmpeg.
It worked, but the performance wasn’t great — CPU utilization was low, and large files took ages to compress.

By moving the compression process to the server side, I could fully leverage the machine’s CPU and I/O performance.
This resulted in much faster compression, especially for longer videos or high-resolution formats (like 1080p or 4K).

It also gave me more flexibility to:

Optimize compression presets dynamically
Handle larger uploads
Support multiple video formats (MP4, MOV, AVI, etc.)

🧪 Lessons Learned

Frontend compression sounds cool, but for heavy workloads, it’s just not efficient.
FFmpeg remains unbeatable when it comes to quality-to-size ratio.
Keeping the UI minimal is key — users just want results, not settings overload.
Building static with Nuxt + FastAPI backend is a great combo for projects like this — quick to build, easy to deploy, and highly scalable.

🌍 Try It Out

If you’d like to give it a try, you can check it out here:
👉 https://videocompress.ai

It’s completely free, no watermarks, no hidden limits.
Would love to hear your feedback or suggestions for improvement!