OmniTools: a self-hosted browser toolbox that processes files on the client

What OmniTools actually is, and the problem it removes

Most people who need to split a PDF, resize a screenshot or reformat a CSV end up on an ad-funded website that uploads the file to a server they cannot inspect. OmniTools is an attempt to remove that step. It is a React and TypeScript application that packages a set of everyday utilities into one interface, and the README states the design constraint plainly: all files are processed entirely on the client side, so nothing leaves the device.

That single sentence decides who the project is for. It fits an engineer who wants an internal utilities page for a team, or a privacy-conscious user who would rather run a container than paste a contract into a random PDF site. It does not fit someone who wants a desktop binary or a mobile app. The repository is a web application with a Dockerfile, and the deployment story in the README is a container on port 80 mapped to a host port.

The scope is deliberately wide rather than deep. The feature list covers image resizing, conversion and editing, video trimming and reversing, PDF splitting, merging and editing, case conversion and list shuffling, date and time zone calculators, prime number generation, Ohm's law calculation, and JSON, CSV and XML tools. Breadth like that usually means each individual tool is simpler than a dedicated application, and the README does not claim otherwise.

How the client-side processing claim is implemented

The mechanism is visible in package.json rather than in prose. The dependency list includes @ffmpeg/ffmpeg, @ffmpeg/core and @ffmpeg/util, which is the WebAssembly build of FFmpeg, plus @imgly/background-removal for image segmentation, @jimp/types for image manipulation, @simplepdf/react-embed-pdf for PDF work, and @monaco-editor/react for the code-oriented tools. Those are browser-side libraries. FFmpeg compiled to WebAssembly runs inside the page, not behind an API route.

That architecture explains both the appeal and the cost. Nothing has to be uploaded, so there is no server-side storage to secure and no retention policy to write. The trade-off is that the browser tab does the work. Video trimming through a WebAssembly FFmpeg build will be bounded by the memory the browser gives a tab, and the README does not publish limits on input file size. If you plan to point the video tools at large files, that is the first thing to check yourself, because the documentation is silent on it.

The build itself is a static site. The Dockerfile runs npm install and npm run build on a node:20 image, then copies the resulting dist directory into an nginx:alpine image. It patches the nginx mime types to serve .mjs files and adds a try_files fallback so client-side routes resolve to index.html. The README describes the resulting image as 28MB, which is consistent with a static bundle served by nginx rather than a Node process. There is no application server in the runtime image, which is why there is nothing to configure for persistence.

Installing OmniTools with Docker and a first real task

The README gives a single command. It pulls the published image, names the container omni-tools, restarts it unless stopped, and maps host port 8080 to port 80 inside the container, which is where nginx listens.

docker run -d --name omni-tools --restart unless-stopped -p 8080:80 iib0011/omni-tools:latest

After that, opening http://localhost:8080 in a browser should show the tool catalogue. There is no database, no volume mount and no environment variable required for a basic run, because the container only serves static files.

If you prefer Compose, the README provides an equivalent definition. The service block uses the same image, the same restart policy and the same port mapping.

services:
  omni-tools:
    image: iib0011/omni-tools:latest
    container_name: omni-tools
    restart: unless-stopped
    ports:
      - "8080:80"

For a first real use, pick a task that exercises the client-side claim: open the PDF splitter, drop in a multi-page document, choose the page range, and export. The file is read by the browser and the output is downloaded from the page; nothing is posted to the container. The same pattern applies to the image converter and the JSON formatter. If you want to build the app yourself instead of pulling the image, the README's development path is a clone followed by npm i and npm run dev, which starts the Vite dev server.

git clone https://github.com/iib0011/omni-tools.git
cd omni-tools
npm i
npm run dev

The repository also exposes a scaffolding script for new tools, npm run script:create:tool, which takes a tool name and a folder path such as split pdf. That is the intended path for adding a utility rather than editing the catalogue by hand.

Where OmniTools is the wrong tool

The client-side model has a hard boundary. Anything that needs a server to hold state, schedule work or process files in bulk is outside what this architecture can do. There is no queue, no job history and no API for automating a conversion from a script. If your workflow is "convert these four hundred images every night", OmniTools is not the component you want.

Memory is the second boundary. A WebAssembly FFmpeg build inside a browser tab competes for the same memory as the rest of the page, and the README does not state a maximum input size for the video or image tools. Treat large media files as untested territory.

The third boundary is quality expectation. The README lists a PDF editor, but the underlying dependency is @simplepdf/react-embed-pdf, which is an embedded PDF component rather than a full document-authoring engine. Anyone expecting Acrobat-level editing of complex layouts, form fields or scanned documents with OCR will be disappointed. The README does not mention OCR anywhere.

Finally, the project's own maintenance signal deserves attention. The repository is not archived, but the last push was on 2025-10-02, and the most recent release listed is v0.6.0 from the same date, following v0.5.0 in July 2025 and v0.4.0 in June 2025. That is a real gap rather than a pause between commits. A tool collection you depend on for daily work should be evaluated with that cadence in mind.

OmniTools compared with a document-focused toolkit

The search data around this project shows people comparing it with Stirling PDF, and the comparison is instructive because the two projects differ in where the work happens, not just in which buttons exist.

Stirling PDF is built as a server-side document processing application. That approach can handle operations a browser tab cannot comfortably do: batch jobs, heavier PDF manipulation, and workflows where the file is processed once on a machine with more memory than a laptop tab. The cost is that files travel to the server, which means the deployment carries a data-handling story.

OmniTools takes the opposite position. The container is a static file server, the computation happens in the visitor's browser, and the README's privacy claim follows directly from that design. The benefit is that self-hosting it does not create a file-retention problem. The cost is the ceiling on file size and the narrower depth of each tool.

There is also a category difference worth naming. OmniTools is a broad utility collection, not a PDF suite. Its JSON, CSV, XML, date and math tools have no equivalent in a document-focused application, and its PDF tools do not match a dedicated one. If your need is overwhelmingly PDF, a document-focused tool is the better fit. If you want one small container that covers a dozen unrelated small tasks without sending anything anywhere, OmniTools is the more economical choice, and the 28MB image size the README cites supports that.

Licence, i18n coverage and the cost of staying current

The project is MIT licensed, with the LICENSE file at the repository root. For most internal deployments that is permissive: you can run it, modify it and redistribute it, provided the copyright notice and permission notice are preserved. This is a description of the licence text, not legal advice; if you are embedding OmniTools in a commercial product, read the file and your own counsel's guidance.

Upgrade cost is low by construction. The runtime artefact is a static bundle in an nginx image, so there are no migrations to run and no schema to reconcile. Updating means pulling a new tag and restarting the container. The README's example uses the latest tag, which means an unattended restart can move you to a new version; pinning a specific tag is the obvious mitigation, and the release list gives you v0.6.0, v0.5.0 and v0.4.0 as candidates.

Translation coverage is a different kind of maintenance cost, and the README publishes a per-language table. Ukrainian is at 100 percent with zero missing keys. Chinese is at 72 percent with 478 missing keys, and Hindi, Russian, German, Spanish, French, Japanese, Dutch and Portuguese sit around 70 to 71 percent with roughly 493 to 515 missing keys each. If you deploy for a non-Ukrainian audience, expect untranslated strings in the interface, and note that the README directs non-developers to the Locize project rather than to the files under public/locales. The .env.example contains a single key, LOCIZE_API_KEY, which is only relevant if you are pulling translations yourself.

Editorial conclusion

Adopt OmniTools if you want a small internal utility page for PDF splitting, image conversion or JSON formatting and you care that uploaded files never reach a server. Skip it if you need server-side batch processing, OCR-grade PDF editing, or a tool with a long release cadence: the last push was on 2025-10-02 and the newest release is v0.6.0. Before rolling it out, open the tools your team actually uses, confirm the client-side processing claim holds for each one (the background-removal and ffmpeg dependencies run in the browser, so check the memory ceiling on your target machines), and read the MIT licence text in the repository's LICENSE file.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes