They would buy a label through MyPost Business, eBay, Shopify or another shipping tool. The platform would give them an A4 PDF. Then they would try to print it on a 4x6 thermal label printer.

That sounds simple until you actually watch someone do it.

Open the PDF. Crop the label. Pick the right printer. Change the paper size to 4x6 or 100x150mm. Hope the margins are not weird. Print a test. Waste a label. Try again.

Do that once and it is annoying. Do it fifty times a week and it becomes one of those tiny operational taxes that nobody wants to think about.

So I built LabelChop, a desktop app that watches your Downloads folder, finds shipping labels, crops them to 4x6, and sends them to your thermal printer automatically.

This post is mostly about the build decisions, because the product looks simple from the outside, but the annoying parts were exactly where you would expect them to be: PDFs, printers, file watchers, and local-first privacy.

In this post

• The problem was not printing, it was repetition

• Why I made it a desktop app

• The basic workflow

• What the stack looks like

• The PDF cropping problem

• Why local-first matters here

• The free converter

• What I would do differently

The problem was not printing, it was repetition

Most shipping platforms already know how to generate a label. Most thermal printers already know how to print one.

The gap is in the middle.

A lot of Australian sellers still end up with A4 label PDFs. That is fine if you are printing on office paper, folding it, and taping it to a parcel. It is painful if you have a proper thermal printer sitting next to you.

The label is usually only one part of the A4 page. The rest might be instructions, receipt details, blank space, or a packing slip. The seller has to turn that A4 page into a clean 4x6 label before printing.

There are workarounds. You can use Adobe Acrobat. You can screenshot. You can change printer scaling. You can use random online PDF tools. You can save presets if your printer driver behaves.

But none of that feels like a real workflow.

The workflow sellers actually want is:

1. Download label.

2. Label prints.

3. Pack the order.

That is it.

Why I made it a desktop app

This could have been a web app, but a web app would have made the core experience worse.

A web app cannot watch your Downloads folder properly. It cannot talk to your local printer the way a desktop app can. It also adds an awkward privacy question because users have to upload shipping labels somewhere.

Shipping labels contain names, addresses and order information. I did not want the main workflow to depend on uploading those PDFs to a server.

That pushed the product toward a local desktop app.

The app needed to:

• watch a folder on the user's machine

• detect new PDF files

• crop the right part of the page

• remember printer settings

• send the cropped label to the selected thermal printer

• stay quiet when nothing needs attention

It is not glamorous. It is very much a "make the boring thing disappear" product.

Those are often my favourite ones.

The basic workflow

The first version of LabelChop is built around a simple loop.

The user chooses a folder, usually Downloads. They choose their thermal printer. They download a shipping label from MyPost Business, eBay, Shopify or another platform. LabelChop notices the file, crops it, and sends it to the printer.

No PDF editor. No manual crop box. No print dialog every time.

For sellers doing a few labels a month, this might be overkill. For sellers printing labels every day, the tiny savings compound quickly.

The goal was not to build a giant shipping platform. There are already enough of those.

The goal was to fix one painful step between buying the label and sticking it on the parcel.

What the stack looks like

The stack is fairly practical:

• Electron for the desktop shell

• Next.js and React for the interface

• pdf-lib for PDF manipulation

• chokidar for file watching

• Supabase for accounts and app state

• Stripe for subscriptions

Electron is not always the lightest choice, but for this use case it made sense. I wanted one codebase, a familiar UI stack, and enough native access to handle local files and printing.

The trick was keeping the app focused. Desktop apps can sprawl fast if you let them.

The early question was always: does this help a seller print labels faster?

If not, it could wait.

The PDF cropping problem

PDFs are where the boring part gets weird.

A label might appear in the top-left corner of an A4 page. Another platform might place it slightly differently. Some PDFs include multiple blocks of content. Some printer drivers interpret scaling in their own special way.

The app needed to produce a predictable 4x6 output without asking the user to understand PDF coordinates.

The simplest useful version was:

• take the A4 PDF

• crop the label area

• create a new 4x6 PDF

• preserve enough quality for barcode scanning

• send that clean PDF to the printer

Barcodes made this less forgiving. A label that looks okay on screen can still scan badly if scaling or rasterisation gets messy.

So the product is less about "cropping a PDF" and more about producing something a thermal printer can handle reliably.

Why local-first matters here

I keep coming back to this point because it is easy to ignore when building tools quickly.

A shipping label is not just a file. It has customer details on it.

For the desktop app, the label processing happens locally. The point is to avoid uploading customer shipping labels just to crop them.

That also changes the trust story. A seller does not need to wonder where their customer's address went. The file is processed on their machine, then printed.

For a tool this small, that matters.

The free converter

I also made a free browser-based tool for one-off labels: the A4 to 4x6 shipping label converter.

That tool is for people who only need to fix one label occasionally. Upload the A4 PDF, choose the crop position, download the 4x6 PDF, then print it.

It does not replace the desktop app. It is more like a pressure valve.

If you are printing labels once in a while, the free converter is enough.

If you download labels all day and want them to print without thinking about it, that is where LabelChop makes more sense.

What I would do differently

I would start with the distribution earlier.

The product problem was obvious once I watched the workflow. The harder part is finding the sellers at the exact moment they are frustrated enough to search for a fix.

That means content like:

• how to crop MyPost Business A4 labels to 4x6

• how to print Australia Post labels on a thermal printer

• 100x150mm label setup for Australian ecommerce sellers

• how to fix shipping labels printing too small

• thermal printer setup for eBay and Shopify labels

Boring searches. High intent.

That is probably the lesson from this build. The best products are not always new categories. Sometimes they are small bridges between tools people already use.

LabelChop is one of those bridges.

It sits between the shipping platform and the printer, then tries to get out of the way.

If you sell online in Australia and keep fighting A4 shipping labels, you can try it here: LabelChop.

For one-off conversions, use the free tool here: A4 to 4x6 shipping label converter.