How I Build and Test Toolium Tools

I get asked, every now and then, what makes Toolium different from the twenty other "free PDF tools" sites that come up in search. The honest answer is the part that does not show up in marketing copy: a stubborn refusal to ship a tool until I have personally tried to break it with the inputs that real users will actually throw at it. This page walks through what that looks like in practice.

The one principle: every tool runs in your browser

There is exactly one architectural rule for Toolium tools: the file you drop on the page never leaves your computer. No upload to a server, no "cloud processing," no temporary storage I would have to promise to delete later. Browsers in 2026 can do an enormous amount of heavy lifting locally, between WebAssembly, Web Workers, the Canvas API, the File API, and a few well-built JavaScript libraries. Everything Toolium does runs on those primitives.

This is not just a privacy talking point. It changes the engineering in ways that matter for users. The tools work offline once the page has loaded. They do not have rate limits because there is no rate limiter; you are paying for your own CPU. They keep working when my server is down because no server is involved. And they get faster as your laptop or phone gets faster, instead of being bottlenecked by a shared backend.

The trade-off is that some operations are genuinely too heavy for the browser. OCR on a 200-page PDF, true AI image upscaling that has to run a 4-gigabyte model, video transcoding that needs hardware encoders all need real servers. I have not built them for that reason, and I am unlikely to add them under the "Toolium" brand. If a tool cannot honestly be done in a browser tab, it does not belong on this site. That is a feature, not a limitation.

How I pick which tools to build next

The starting point is almost always a specific personal annoyance. PDF Merge was the first tool I built because I had spent a stupid amount of time trying to combine a signed lease with its attachments on a Monday morning, and every free site I tried either added a watermark, required signup, or made me wait in a queue while it uploaded my private document to a server in some country I have never been to.

That pattern repeats for almost every Toolium tool. JSON Visualizer came from staring at a 4,000-line API response and not being able to remember whether it was the "orders" key or "line_items" that held the array I cared about. Regex Tester came from getting bitten by a catastrophic-backtracking pattern in production code; I wanted a tester that would not freeze the page while I tried variations.

When I have an annoyance, I check whether anyone else has built a good free tool for it. If somebody already has (really has, not just a thin wrapper with three ads on top), I do not bother. If the existing free options are all either limited, ad-spammed, or server-side, that tool goes on the list.

How a tool gets built

The build itself is usually the easy part because the open-source ecosystem for browser-side processing has gotten incredibly good. For PDF work I use pdf-lib (for manipulation) and pdf.js (for rendering). For image work, browser-image-compression handles the heavy lifting for compression, and the native Canvas API handles resize, crop, and format conversion. For spreadsheets, SheetJS reads and writes .xlsx. For JSON tools, the built-in JSON parser plus Dagre for visualization gets you most of the way there.

Where Toolium tools usually diverge from a quick-and-dirty implementation is in handling the edges. The default-happy-path version of any of these tools is honestly a half-day of work. The version that handles the inputs real users will give it takes a couple of weeks, and most of it is not visible in the interface.

Edge cases I have actually shipped fixes for

A short, very partial list of bugs I have fixed in production after shipping a "working" tool. I list them here because they are the kind of detail you only get from building something and letting real users find the corners:

Image Compressor and Format Converter: the first version turned transparent PNGs into JPGs with a black background because the canvas API initialises the backing buffer to transparent black and JPEG cannot encode alpha. The fix was to composite the image onto a white rectangle before handing it to the JPEG encoder. Obvious in hindsight; not so obvious when you are looking at a black-bordered output and trying to figure out where the black came from.
Markdown Preview: the first version happily rendered raw HTML from the markdown source, including <script> tags. A friend pointed out that this was a textbook XSS vulnerability and I should fix it before anyone else noticed. I added DOMPurify between the markdown parser and the rendered output, which sanitises the HTML without breaking legitimate markdown features.
Regex Tester: the first version ran the regex on the main thread, which meant that if you typed something like (a+)+band pasted a long string of a's, the page would freeze and the user would have to close the tab. I moved execution to a Web Worker with a 1-second timeout. If the regex takes too long, the worker gets terminated and the user sees a warning instead of a frozen tab.
JWT Decoder: the first version assumed UTF-8 was ASCII and mishandled non-Latin characters in JWT claims. Tokens issued by Russian and Japanese services produced garbled output. The fix was to route the base64url decode through TextDecoder instead of using the legacy atob/charCodeAt approach.
Word Counter:the first version undercounted sentences whose endings contained abbreviations ("Dr.", "St.", "etc.") and could not segment Chinese or Japanese text at all because those languages do not use spaces between words. Switching to Intl.Segmenter (where available) and adding an abbreviation list got the counts much closer to what Microsoft Word produces.
Diff Checker:the first version was O(N²) because of a naive line-comparison loop, which made anything over a few thousand lines unusable. Switching to an LCS dynamic-programming diff with common prefix and suffix trimming, and pre-computing line hashes, made even comparisons feel instant right up to the point where the tool refuses, which is four million LCS cells after common prefix and suffix trimming, roughly a 2,000-by-2,000-line changed region.
Image Cropper: the first version used mousedown and mousemove for the crop handles, which broke on touchscreens because those events do not fire reliably on mobile. I rewrote it to use Pointer Events, which work uniformly across mouse, pen, and touch input.
PDF tools across the board: several tools used to silently corrupt password-protected PDFs by attempting to read them without a password, then producing a malformed output that looked fine until you tried to open it. They now detect encryption up front and tell you they cannot help, instead of producing a broken file you discover an hour later when you go to send it.
Color Picker: the first version did not handle three-digit hex codes (#F63) or decimal RGB notation, which surprised users coming from CSS where both are legal. Now both parse correctly.
JSON Visualizer: the first version made every scroll gesture inside the canvas zoom the diagram, which felt terrible on a trackpad because horizontal scroll was constantly being interpreted as zoom. I added gesture detection so trackpad two-finger scroll pans the canvas, and ctrl+scroll zooms, which is the convention that figma and most modern design tools use.

Most of these were not in the original spec because most of them are only visible once a real user hits them. Browser APIs in particular have a long tail of subtle gotchas that only show up with non-ASCII input, non-Latin scripts, mobile devices, or files produced by older software. The methodology, such as it is, is to fix them quickly when reports come in and write a guide section explaining what to expect.

What I do not do, and why

I do not collect emails to use the tools. Every tool on Toolium works without an account. The email capture on the home page is opt-in and only sends a note when I ship something new. Most days it sends nothing.

I do not upload your files for "processing." I cannot stress this enough because almost every other free tool site does. Open the network tab in your browser's dev tools while you use any Toolium tool. You will see analytics requests and ad requests, but you will not see your file. Because it never leaves the machine.

I do not add features just to look feature-complete. Some tools could have a hundred options. PDF Merge could let you reorder pages within each file, add bookmarks, set metadata, sign with a certificate, and so on. The version on Toolium does one thing well: combine PDFs in the order you arrange them. If I cannot find a situation where someone actually needs an option, the option does not ship.

I do not run ads on tool interfaces, only below them. The ad slots on Toolium are at the bottom of pages, never inline with the tool you are trying to use. You should never have to dodge an ad to click a button.

Honest limitations

Some things I will not pretend to do well:

Truly huge files. Browser memory limits are real. A 500 MB PDF or a 4 K video are not Toolium territory. Each individual tool guide says where its practical limit sits.
OCR. Tesseract.js exists and can do OCR in the browser, but the quality on scanned documents is not good enough for me to ship as a real tool, and the memory cost is brutal. I would rather not have OCR than ship bad OCR.
True image upscaling. The browser can scale images up, but it cannot invent the detail that was not there. Real upscaling needs an AI model, and the good ones are too large to run in a browser tab.
Editing-style PDF tools. No filling out PDF forms, no redaction, no inline text editing. pdf-lib does not support that well in browsers and the user experience would be worse than just opening the PDF in Preview or Acrobat.
Anything that needs current data. Currency conversion is the obvious one. The exchange rate changes constantly and I do not run a backend to fetch it, so a converter here would either be wrong or would have to phone home, and both options break the one rule this site has.

The per-tool guides on each tool page repeat the limitations relevant to that tool. The intention is that you find out what the tool will not do before you spend time trying.

How this site is structured, in case you are curious

The site is a Next.js 16 application using the App Router, deployed on Vercel. Tools are individual route segments under /tools. The static content (this page, the About page, the blog) is generated at build time, so the entire tools-content portion of the site is just static HTML and JS bundles. Tailwind CSS handles the styling. The dark mode toggle uses next-themes plus a small set of design tokens defined in CSS variables.

The interesting bits, from an engineering standpoint, are the tools themselves. Each one is a single React component with a handful of dynamic imports for the heavy libraries: pdf-lib only loads when you visit a PDF tool, SheetJS only loads when you visit a spreadsheet tool, and so on. The result is a homepage that loads in under a second on a desktop browser and stays light because the 90 KB of pdf-lib does not get shipped to a user who only needs the password generator.

What I am working on next

Today, in June 2026, the active work is around three threads: improving accessibility on the more complex tools (Diff Checker and JSON Visualizer especially), expanding the per-tool guides to include video walkthroughs for the tools where a video would actually help, and a handful of new tools that have made the shortlist after a few people asked for them: most likely an audio format converter, an EXIF metadata stripper, and a markdown table generator. None are guaranteed to ship; if I cannot do them well in a browser tab without compromising the privacy or honesty principles above, they will not ship under this name.

If you want to help

The best help is a bug report. If a tool produced wrong output for you, or threw an error you did not understand, or just felt slow on your machine, email dev@devtoolium.com with what you tried, what you expected, and ideally a small example. I read every message and most bugs get fixed within a few days.

The second-best help is suggesting a tool you wish existed. I keep a list. About half the tools currently on Toolium were suggested by someone other than me. If you have a workflow that is annoying and feels like it should be doable in a browser, tell me about it.