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?

Comments

[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.

[UtiHub]

Thanks for the detailed scan — good catch. I’ve now shipped an enforced Content Security Policy and the missing browser hardening headers: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. I also removed the X-Powered-By header.
The changes are live on utihub.com. I verified the production response headers directly and ran the full unit, production build, and browser test suites across desktop, tablet, and mobile.
I’d appreciate a re-scan when you have a chance.

[Amit Feldman]

Re-scanned just now — everything you listed checks out on production:

CSP is live and enforcing (not report-only): default-src 'self', script-src-attr 'none' — the "an injected script can't exfiltrate what a user pastes" guarantee is now actually backed by the header. X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a locked-down Permissions-Policy (camera/mic/geolocation/payment/usb all off). X-Powered-By gone, HSTS still at 2-year.

Full pass: 16 checks green, 0 warnings, 0 failures — that's the whole security-header block closed in under a day. Nice shipping.

One optional level-up, whenever: script-src still allows 'unsafe-inline'. Moving to nonces or hashes kills inline injection entirely, but that's a refactor, not a header rule — completely reasonable to defer.

Since this went from "no CSP" to "all six headers green" in a day: would you be open to a short before/after write-up of this fix as a case study (you'd review the wording before anything goes up)? Concrete turnaround stories like this are more useful to other launchers than generic advice — no worries either way.

[UtiHub]

Thanks, Amit — I really appreciate you taking the time to re-scan it and confirm the fixes in production.

Yes, I’d be open to a short before/after case study. Please send me the draft before publishing so I can review the technical details and wording. Feel free to mention UtiHub and link to the site.

I also agree that replacing unsafe-inline with nonces or hashes would be a good next security improvement. I’ll treat that as a separate refactor.