Lumarc Studio

Engineering · September 15, 2026

How We Built 63 Browser-Based Developer Tools Without a Backend

A technical breakdown of how Lumarc Studio built a suite of 63 developer tools that run entirely in the browser using static site generation, Web APIs and zero server dependencies.

When we set out to build Lumarc DevTools, we had one guiding constraint: every tool must run entirely in the user’s browser. No backend servers. No user accounts. No data uploads. No analytics scripts tracking what you paste into a JSON formatter.

This article explains the technical decisions behind building a suite of 63 developer tools as a static site, what we learned along the way and where browser APIs made the approach practical.

Why local-first matters for developer tools

Developer tools handle sensitive data. API keys end up in JSON payloads. Passwords get tested in strength checkers. Private configuration files get formatted. Base64-encoded tokens get decoded.

Sending any of this to a server creates unnecessary risk. It also creates unnecessary cost, latency and operational complexity. If a JSON formatter can run in the browser, it should run in the browser.

We wanted developers to reach for Lumarc DevTools with the same confidence they have in a local terminal command. That meant no network requests for tool operations, no cookies beyond an optional theme preference and no JavaScript execution of user input in the main thread.

The static site architecture

Lumarc DevTools is built with Astro as a fully static site. Each tool page is pre-rendered at build time with its own metadata, structured data and descriptive content. The tool interface itself loads as a self-contained script that operates on the DOM without fetching external resources.

The architecture looks like this:

  • Static HTML pages generated at build time with Astro
  • Per-tool JavaScript modules loaded only on the pages that need them
  • No framework runtime shipped to the client for most tools
  • Web Workers used for computationally intensive operations like image processing
  • Canvas API for image manipulation tools (compressor, resizer, WebP converter)
  • Crypto API for UUID generation and password generation
  • Clipboard API for one-click copy results

Each tool is effectively a standalone micro-application embedded in a consistent page shell. This keeps bundle sizes small and avoids loading unnecessary code.

Handling different tool categories

The 63 tools span several categories, each with different technical requirements:

Text and data tools

JSON formatters, YAML converters, Base64 encoders and regex testers all work with string manipulation. These are the simplest tools technically — they parse input, transform it and render output. The main challenge is providing clear, useful error messages when input is malformed.

For JSON tools specifically, we use a custom parser that provides line and column numbers for syntax errors, rather than relying on the generic messages from JSON.parse().

Image tools

The image compressor, resizer, favicon generator and WebP converter use the Canvas API and OffscreenCanvas. Processing happens in a Web Worker to avoid blocking the main thread during large image operations.

File handling uses the File API and drag-and-drop events. Output images are generated as Blob URLs for preview and download. No image data leaves the browser.

Generator tools

UUID generation uses crypto.getRandomValues() for cryptographically secure randomness. The password generator uses the same API with configurable character sets, length and entropy estimation.

QR code generation uses a lightweight library that renders to Canvas, with export to PNG and SVG formats.

SEO tools

Meta tag generators, SERP preview tools and schema markup generators work with structured form inputs that produce copy-ready code snippets. These required careful validation logic to match Google’s actual truncation behaviour for titles and descriptions.

What browser APIs made possible

Several Web APIs were essential to making the local-first approach work:

  • Crypto API (crypto.getRandomValues, crypto.subtle) for secure generation without external libraries
  • Canvas and OffscreenCanvas for image processing without server-side tools like Sharp or ImageMagick
  • Clipboard API for seamless copy-to-clipboard across all tools
  • File API and Blob URLs for handling file inputs and generating downloadable outputs
  • TextEncoder and TextDecoder for proper UTF-8 handling in encoding tools
  • Web Workers for offloading intensive operations without freezing the interface

The Web platform is genuinely powerful enough to replace most common developer utility backends. The main limitation we encountered was file format support — some image format conversions that are trivial with server-side libraries require creative workarounds in the browser.

Performance considerations

With 63 tools, we paid close attention to page load performance:

  • Each tool page loads only its own JavaScript module, not the entire tool suite
  • Common utilities are shared through small, tree-shakeable modules
  • No JavaScript framework runtime is shipped for static tool pages
  • Images are lazy-loaded and use modern formats where supported
  • The entire site scores consistently above 95 on Lighthouse performance audits

Lessons learned

Start with the constraint. “No backend” forced us to think carefully about what the browser can actually do. In most cases, it can do more than you expect.

Error messages are the product. For developer tools, the quality of error feedback matters more than the happy path. A JSON formatter that says “invalid JSON” is almost useless. One that says “unexpected comma at line 7, column 23” is genuinely helpful.

Consistency across tools matters. Developers build muscle memory. If the copy button is in a different position on each tool page, or if keyboard shortcuts vary, the suite feels like 63 unrelated tools rather than one coherent product.

Privacy is a feature, not a constraint. We initially chose local-first processing for ethical reasons. It turned out to be a competitive advantage too. Developers actively prefer tools that do not require accounts or data uploads.

What comes next

We continue to add tools based on what developers actually need in their daily workflows. The tool suite has grown from the initial launch set to 63 tools, with planned additions in JavaScript debugging, data inspection and QA testing categories.

If you want to try any of these tools, visit tools.lumarcstudio.com. Everything runs in your browser.