DEV Community

Cover image for Why We Rebuilt Popular Web Utilities to Run 100% Client-Side
Muhammad Umair | DevOmniTools
Muhammad Umair | DevOmniTools

Posted on AI-assisted

Why We Rebuilt Popular Web Utilities to Run 100% Client-Side

The Silent Security Risk in Modern Developer Utilities

The Problem With Traditional Online Developer Utilities - Server Logging Risks

As software engineers, we are drilled on defense-in-depth: zero-trust network policies, encrypted-at-rest databases, rotating service principals, and strict CORS headers.

Yet, during daily incident triage or local testing, a common developer workflow looks like this:

  1. An authentication issue arises on staging -> you grab an active user's Bearer JWT token and paste it into a web decoder.
  2. Search crawlers start indexing internal endpoints -> you paste your draft robots.txt file containing private staging and API routes into an online validator.
  3. A backend service throws an encoding error -> you copy-paste base64-encoded binary blobs or SQL dump queries into an online formatter.

The Problem With Server-Side Utilities

A massive percentage of free utility websites operate on traditional server-side rendering pipelines (Node.js/Express, Python/Flask, Go, or PHP). When you click "Decode", "Format", or "Validate":

  • Your token or payload travels over HTTP to a 3rd-party server.
  • Reverse proxies (Nginx/Envoy/Cloudflare) terminate TLS and record request bodies or headers in application access logs.
  • Cloud Application Performance Monitoring (APM) tools (Datadog, New Relic, Sentry) capture unscrubbed parameters during debug logging.
  • Telemetry engines and analytics pixels observe user interactions with the page.

If that server gets breached, or a rogue analytics script scrapes the DOM, your confidential tokens, user scopes, and internal architecture become public knowledge.

We believed developers shouldn't have to choose between convenience and confidentiality. That is why we built and open-sourced DevOmniTools ## The Silent Security Risk in Modern Developer Utilities

The Problem With Traditional Online Developer Utilities - Server Logging Risks

As software engineers, we are drilled on defense-in-depth: zero-trust network policies, encrypted-at-rest databases, rotating service principals, and strict CORS headers.

Yet, during daily incident triage or local testing, a common developer workflow looks like this:

  1. An authentication issue arises on staging -> you grab an active user's Bearer JWT token and paste it into a web decoder.
  2. Search crawlers start indexing internal endpoints -> you paste your draft robots.txt file containing private staging and API routes into an online validator.
  3. A backend service throws an encoding error -> you copy-paste base64-encoded binary blobs or SQL dump queries into an online formatter.

The Problem With Server-Side Utilities

A massive percentage of free utility websites operate on traditional server-side rendering pipelines (Node.js/Express, Python/Flask, Go, or PHP). When you click "Decode", "Format", or "Validate":

  • Your token or payload travels over HTTP to a 3rd-party server.
  • Reverse proxies (Nginx/Envoy/Cloudflare) terminate TLS and record request bodies or headers in application access logs.
  • Cloud Application Performance Monitoring (APM) tools (Datadog, New Relic, Sentry) capture unscrubbed parameters during debug logging.
  • Telemetry engines and analytics pixels observe user interactions with the page.

If that server gets breached, or a rogue analytics script scrapes the DOM, your confidential tokens, user scopes, and internal architecture become public knowledge.

We believed developers shouldn't have to choose between convenience and confidentiality. That is why we built and open-sourced DevOmniTools - an ecosystem of 79+ developer tools running with 100% client-side execution, zero API proxies, and zero telemetry.


Architectural Breakdown: How Zero-Leakage Actually Works

DevOmniTools Client-Side Architecture Diagram

Here is the engineering reality behind running complex developer tooling inside the browser sandbox:

+--------------------------------------------------------+
|                   BROWSER ISOLATION                    |
|                                                        |
|  [Sensitive Input]                                     |
|        |                                               |
|        v                                               |
|  [Web Worker Thread] --- RFC 9309 Parser (Zero Telemetry)
|                      --- Base64URL Stream Decode       |
|                      --- W3C Web Cryptography API      |
|        v                                               |
|  [Structured DOM]                                      |
+--------------------------------------------------------+
                 X NO HTTP BACKEND CALLS X
+--------------------------------------------------------+
|                  STATIC CDN / EDGE                     |
|                (Pre-rendered Assets)                   |
+--------------------------------------------------------+
Enter fullscreen mode Exit fullscreen mode

1. Decoding JWTs & JWS Safely (RFC 7515 / 7519)

A standard signed JWT is a compact serialization of three dot-separated Base64URL strings: Header.Payload.Signature.

Instead of transmitting this token to a remote server, our JWT & JWS Decoder decodes the segments locally using native browser string operations:

export function decodeJwtLocally(token: string) {
  const parts = token.trim().split('.');
  if (parts.length !== 3) {
    throw new Error('Invalid JWT: Expected 3 compact serialization segments.');
  }

  // Base64URL to Base64 standard padding
  const decodeSegment = (seg: string) => {
    let base64 = seg.replace(/-/g, '+').replace(/_/g, '/');
    while (base64.length % 4) base64 += '=';
    const json = decodeURIComponent(
      Array.prototype.map
        .call(atob(base64), (c: string) => '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2))
        .join('')
    );
    return JSON.parse(json);
  };

  const header = decodeSegment(parts[0]);
  const payload = decodeSegment(parts[1]);

  return { header, payload, signaturePresent: Boolean(parts[2]) };
}
Enter fullscreen mode Exit fullscreen mode

Why this matters: Your sensitive claims (sub, roles, tenant_id, email) remain exclusively in client RAM and disappear the moment you close the tab.


2. Validating Robots.txt Rules Without Exposing Private Paths

When configuring robots.txt, engineers often declare Disallow: /admin-internal/, Disallow: /staging-api/, or specify secret crawler user-agents (GPTBot, ClaudeBot, Googlebot).

Online validators that require a public URL or fetch through their servers leak these staging patterns. With our Robots.txt Tester & Validator, syntax validation strictly complies with RFC 9309 inside a dedicated client-side worker:

// Client-side RFC 9309 Path Matching Logic
export function isPathAllowed(pattern: string, testPath: string): boolean {
  // RFC 9309 rule precedence: end-of-line marker '$' and wildcard '*'
  const escaped = pattern
    .replace(/[.+?^${}()|[\]\\]/g, '\\$&')
    .replace(/\*/g, '.*');

  const regex = new RegExp('^' + escaped);
  return regex.test(testPath);
}
Enter fullscreen mode Exit fullscreen mode

You can simulate any bot path matching, verify AI bot disallows, and catch syntax errors without a single packet leaving your laptop.


3. Converting SVG to Icon Fonts Client-Side

Converting vector icons to web fonts (TTF, WOFF2) traditionally requires heavy server-side Python libraries (fontforge, fonttools).

Through client-side WebAssembly and JavaScript vector compilers in our SVG to Font Converter, vector coordinates are parsed directly into TrueType glyph tables in browser memory, generating downloadable font packages with zero server uploads.


Key Lessons Learned Building Client-Side Developer Tools

  1. Leverage Modern Browser Standards: The Web Platform in 2026 is absurdly powerful. The W3C SubtleCrypto API is hardware-accelerated. Web Workers eliminate UI freezing during 50MB JSON parses.
  2. Never Compromise on Network Cleanliness: Check your Network Tab. When using a developer tool, if you see POST or PUT requests containing your payload, find an alternative or build a local script.
  3. Open-Source Everything: Trust is earned through verifiable code. We keep the entire architecture open for review so any developer can audit the source.

Try It & Check Your Network Tab

DevOmniTools Developer Utilities UI Showcase

If you want fast, privacy-first developer utilities that respect your data:

How does your team handle confidential data when debugging in development environments? Let's discuss in the comments below!

Top comments (0)