There are a lot of small tasks developers do surprisingly often:
- resize an image
- convert an image format
- merge a couple of PDFs
- extract text from an image
- generate a QR code
- count words
- remove a page from a PDF
None of these tasks are particularly difficult.
The annoying part is finding a tool for them.
You search for one, land on a website covered in ads, upload your file, close three popups, get asked to create an account, and finally discover that the "free" version has a file-size limit.
So I've started thinking about these tools differently.
Does this actually need a server?
This is probably the first question worth asking.
For some operations, the browser already gives us most of what we need.
Take image resizing.
A file can be loaded into the browser, drawn onto a canvas, and exported again:
const image = new Image();
image.onload = () => {
const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");
canvas.width = 800;
canvas.height = 600;
ctx.drawImage(image, 0, 0, 800, 600);
canvas.toBlob((blob) => {
// Download or use the processed image
}, "image/jpeg");
};
image.src = URL.createObjectURL(file);
No API request.
No database.
No file upload service.
For a simple transformation, the browser is already the processing environment.
And that has another advantage:
the file doesn't necessarily have to leave the user's device.
But client-side processing isn't automatically better
This is where things get interesting.
A 2 MB JPEG doesn't mean the browser only needs 2 MB of memory.
Suppose the image is 4000 × 3000 pixels.
That's 12 million pixels.
With 4 bytes per pixel for RGBA:
12,000,000 × 4
= 48,000,000 bytes
That's roughly 48 MB just for raw pixel data.
Now add the original file, decoded image, canvas, output blob, previews, and potentially another copy.
Suddenly a "small" image-processing operation isn't so small.
That's why an application can work perfectly during development and then behave badly when someone uploads a photo straight from a modern phone.
The same problem appears with PDFs
PDF tools have a similar problem.
A PDF with 50 pages shouldn't necessarily mean:
Render all 50 pages at maximum quality immediately.
For a preview interface, thumbnails are enough initially.
Then, when the user selects a page:
PDF
│
├── Page 1 → thumbnail
├── Page 2 → thumbnail
├── Page 3 → thumbnail
├── ...
│
└── Page 50 → thumbnail
User selects Page 23
↓
Render Page 23 at a larger size
This is a small architectural decision, but it makes a noticeable difference to perceived performance.
The application isn't necessarily doing less work overall.
It's doing the work when it becomes useful.
Object URLs are another small thing worth remembering
For previews, you don't always need to convert a file into base64.
const url = URL.createObjectURL(file);
Then:
<img src={url} alt="Preview" />
Simple.
But there's a catch:
URL.revokeObjectURL(url);
If an application repeatedly creates object URLs and never releases them, memory can accumulate.
These are the kinds of details that don't matter much in a tutorial example.
They matter much more in an application where users can upload, replace, preview, and process files repeatedly.
Maybe we have too many separate tools
There's also a UX problem here.
If someone needs to remove one PDF page, they probably don't want to install a PDF application.
If someone needs to convert PNG to JPG once, they probably don't want another desktop application.
If someone needs to generate a QR code once, they probably don't want an account.
For occasional tasks, a lightweight browser utility often makes more sense.
I've been collecting some of these small utilities in one place for exactly that reason:
PixelTrim — https://pixeltrim.vercel.app/
It has PDF, image, text, calculator, and developer utilities.
But the interesting part isn't really the website.
The interesting part is how much functionality modern browsers can provide without turning every tiny task into a full SaaS application.
The browser is more capable than we give it credit for
Between:
- File API
- Blob
- ArrayBuffer
- Canvas
- Web Workers
- Web Crypto
- WebAssembly
- IndexedDB
- URL APIs
there's a surprisingly large amount of work that can happen locally.
Of course, server-side processing still makes sense for plenty of situations.
Large files, expensive computation, persistent storage, collaboration, authentication, and workflows that require backend infrastructure are obvious examples.
But for small utilities, it's worth asking one question before reaching for an API:
Can the browser already do this?
Sometimes the simplest backend is no backend at all.