DEV Community

UtiHub
UtiHub

Posted on

I rebuilt my utility site around private browser-based developer tools

Developers regularly paste JSON, URLs, tokens, and code snippets into online utilities. The task is usually small, but the input may still contain project names, internal endpoints, or other details that should not leave the browser.

I rebuilt UtiHub around a narrower idea: focused developer tools that work immediately, require no account, and keep supported tool input local.

Starting with JavaScript minification

The first workflow I concentrated on was JavaScript minification. The current JavaScript Minifier uses Terser and provides:

  • minify and beautify modes;
  • ES2015, ES2020, and ES2022 targets;
  • optional compression and name mangling;
  • module parsing;
  • local .js, .mjs, and .cjs file input;
  • source and output byte comparison;
  • copy and download actions.

The important constraint is that UtiHub does not upload or execute the source. Processing happens in the browser tab.

Applying the same constraint to other tools

That same principle applies to tools such as the JSON Formatter, URL Parser, JWT Decoder, Regex Tester, and Base64 Encoder/Decoder.

The difficult part was not adding more utilities. It was reducing the product to a promise people could understand: private browser tools for everyday developer tasks.

You can try the JavaScript Minifier or browse the full collection at UtiHub.

I would appreciate practical feedback: which developer task would you still avoid doing in an online tool, even if it claimed to process data locally?

Top comments (1)

Collapse
 
amitfeldman profile image
Amit Feldman

Rebuilding around privacy-first, browser-based tools is the right differentiation — "runs locally" is the one claim in this category a skeptical user can actually verify in devtools.

I ran a quick launch check on utihub.com. The good news first: HSTS is solid (2-year max-age), TTFB is 391ms, and the SEO basics are clean — title, meta description, single h1, robots.txt and sitemap all live. One real gap: no Content-Security-Policy. It matters more for you than most sites, because CSP is the header that technically backs the privacy pitch — default-src 'self' means even an injected script (compromised dependency, XSS) can't exfiltrate whatever a user pastes into your formatters. Right now nothing blocks that.

Also missing: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — depending on your host those four are usually one edge rule, no deploy.

Happy to re-scan once it lands and confirm the fix.