I’ve been working on DevToolbox, an open-source browser workspace that brings common developer utilities together in one place.
The project currently includes 37 tools for working with code, structured data, images, PDFs, archives, encoders, generators, and other everyday developer tasks.
But the main goal was never simply to build another collection of online tools.
I wanted the tools to work together while keeping processing as local and private as possible.
Why I built DevToolbox
There are many great online developer utilities, but I often found myself jumping between different websites for simple tasks:
- formatting JSON
- inspecting files
- converting images
- working with PDFs
- generating hashes
- testing regular expressions
- converting structured data
- creating ZIP archives
Another concern was file processing.
For many small developer tasks, uploading a file to a remote service feels unnecessary.
So I started building DevToolbox around a simple principle:
Process supported inputs locally in the browser whenever possible.
DevToolbox does not require an account, and it does not use a conversion backend or analytics service.
37 tools, one workspace
Instead of treating every tool as an isolated page, DevToolbox includes a persistent Workspace backed by IndexedDB.
A file can be imported once and reused by compatible tools.
For example:
PDF
↓
PDF → Images
↓
Workspace
↓
Image Cropper
↓
Image Compressor
↓
Download
This makes the application feel more like a small browser-based developer workspace than a directory of unrelated utilities.
The central tool registry
One architectural decision that became increasingly useful as the project grew was keeping tool metadata in a central registry.
The registry drives things such as:
- routes
- categories
- global search
- favorites
- recently used tools
- file compatibility
- Workspace handoffs
- related-tool recommendations
That means adding or changing a tool does not require maintaining the same metadata independently across several parts of the UI.
With 37 tools, this became especially important.
What changed in v4.1
The latest release focuses heavily on the Workspace.
Workspace Collections
Files can now be organized into collections.
Users can:
- create collections
- rename them
- move individual files
- move multiple selected files
- filter the Workspace by collection
Deleting a collection does not delete the files inside it.
The IndexedDB schema was also migrated additively so existing Workspace data is preserved.
Smart File Inspector
The new Smart File Inspector can inspect supported files locally.
It currently understands formats such as:
- images
- PDFs
- JSON
- ZIP archives
It can examine metadata and recommend compatible DevToolbox tools.
For supported binary formats, detection can also use file signatures instead of relying only on the reported MIME type or filename.
The inspector is intentionally deterministic.
It does not send files to an AI service or backend.
Package.json Analyzer
I also added a local package.json analyzer.
It can display:
- project metadata
- dependency groups
- scripts
- structural diagnostics
Input can come from pasted JSON, a local file, or the DevToolbox Workspace.
It does not query npm or claim that a dependency is outdated or vulnerable.
The analysis is based only on the provided file.
Local processing and workers
Some tasks are heavier than simple text transformations.
DevToolbox uses browser-side processing for features including:
- PDF operations
- PDF.js rendering
- ZIP processing with fflate
- code formatting with Prettier
Where appropriate, heavier work is moved into local workers.
This helps keep the UI responsive without introducing a processing backend.
PWA and offline support
DevToolbox is also installable as a PWA.
After the required assets have been cached, many parts of the application can continue working without a network connection.
Workspace files remain separate from the service-worker cache and are stored locally through IndexedDB.
Privacy by design
The current architecture intentionally avoids several things:
- no account system
- no analytics
- no automatic cloud upload
- no conversion API
- no backend required for supported processing
Files only leave the application when the user explicitly downloads or exports something.
Testing the project
As the number of tools increased, regression testing became much more important.
The project currently includes unit and end-to-end coverage, and the application is verified across:
- Chromium
- Firefox
- WebKit
The GitHub Pages production build is also tested with the /DevToolbox/ base path because routing and asset paths can behave differently when an application is hosted inside a repository subdirectory.
Tech stack
The main stack currently includes:
- React 19
- TypeScript 6
- Vite 8
- Tailwind CSS 4
- React Router
- IndexedDB
- vite-plugin-pwa
- pdf-lib
- PDF.js
- fflate
- Prettier
The project is completely open source.
Try it
Live application:
https://can-ozan.github.io/DevToolbox/
Source code:
https://github.com/Can-Ozan/DevToolbox
I’m particularly interested in feedback about the Workspace model.
Does moving files between compatible browser tools feel useful compared with using isolated utilities?
I’d also like to hear which developer tools you think would fit naturally into a local-first workspace.
Top comments (0)