Building DevToolbox: 37 Local-First Developer Tools in One Browser Workspace

Yusuf Can Ozan — Thu, 01 Oct 2026 14:44:41 +0000

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.

Most GitHub README Generators out there feel identical and lacking. 🤦‍♂️ I'm building a modern, highly customizable open-source tool. What’s that ONE feature you always wished a profile README generator had? Drop your thoughts below! 👇 #buildinpublic

Yusuf Can Ozan — Wed, 22 Jul 2026 14:37:51 +0000

DEV Community: Yusuf Can Ozan