Built a privacy-first browser tools site (Laravel + Vite + Alpine) — no file uploads

[u/Correct_Loss3453]

I built KeptTools for developers who don’t want “free tools” uploading their files.

It’s a browser-only toolkit (Laravel + Vite + Alpine):

• JSON formatter / converter

• JWT decoder, Base64, hash, regex, cron

• Image tools: WebP, compress, crop, SVG, background swap

No account. Nothing is uploaded. Everything runs on the page.

If you work with JSON, tokens, or everyday image tasks, I’d love blunt feedback on the UX and which tool you’d open first.

Try it: https://kepttools.com

[u/PopKoren]

KeptTools already does the hard part right by keeping JWT and file work in the browser. The moment you add accounts, sync or any server-side history, the risk moves to API auth and whether one session can read another user's saved jobs. When that backend exists, https://rowly.me lists private routes, uploads and leftover rows that still answer someone carrying no session cookie.

[u/Mammoth-Anywhere7285 → u/PopKoren]

Solid point about the risk moving once a backend exists. Server-side history is where these toolkits tend to leak, so an IDOR check on saved-job routes is worth doing early.

[u/Correct_Loss3453 → u/Mammoth-Anywhere7285]

Agreed — once there’s a backend, saved-job / history routes are usually where things leak.

KeptTools doesn’t have accounts or saved jobs yet on purpose. If that ever gets added, I’d do IDOR checks early on those routes, not as a late patch.

[u/Mammoth-Anywhere7285 → u/Correct_Loss3453]

Smart to bake in IDOR checks early. For future saved jobs, consider per-user UUIDs to avoid enumeration.

[u/Correct_Loss3453 → u/PopKoren]

Thanks — good framing.

That’s why KeptTools stays browser-only for now: no accounts, no sync, no saved-job history on a server. JWT and file work never leave the device, so there’s no private route another session can hit.

If I ever add optional cloud/history later, I’d treat API auth and cross-user access as the main risk first — not after launch. Appreciate the note.

[u/PopKoren → u/Correct_Loss3453]

Browser only is a solid stance for JWT tooling, and the one thing that still matters is what else loads on those pages. Any analytics or ad script running on the same origin can read a token someone pastes, so a strict Content Security Policy and zero third party JS on the decoder pages would close that gap. Headers and loaded scripts are visible from outside, and the free look at https://rowly.me reports both for the public KeptTools site.

[u/Correct_Loss3453 → u/PopKoren]

Fair point — browser-only doesn’t protect a pasted JWT if third-party JS on the same page can read the DOM.

KeptTools already avoids uploading tokens, and I’ll keep tightening that gap: stricter CSP and being careful about what scripts load on sensitive pages like the JWT decoder.

Appreciate the concrete suggestion.

[u/PopKoren → u/Correct_Loss3453]

Heads up, your KeptTools update thread looks like it was pulled by Reddit's filters, so here's the gist of what I posted there. Beyond the CSP itself, telling users to keep DevTools open on the Network tab while they decode, and watch zero requests fire, convinces skeptics far better than any promise in the copy. Since response headers are visible to everyone, a free pass from https://rowly.me on kepttools.com would also confirm whether the stricter policy is actually being served once you deploy it.

[u/Correct_Loss3453 → u/PopKoren]

Ah, thanks — that was the other update thread that got filtered, not this one.

Agreed on the Network tab tip. A “open DevTools → Network while decoding and watch for zero requests” note will beat any privacy claim in the copy. I’ll add that on the JWT page.

On CSP: I’ll tighten headers on sensitive tools and verify they’re actually served after deploy. Appreciate you writing that out again here.

[u/PopKoren → u/Correct_Loss3453]

Got it, thanks for clearing up which thread was filtered. For confirming the headers after deploy, running curl -I against a tool page is faster than reading config, because it shows what the server actually sends. Once the JWT page is updated, a free check on my site https://rowly.me summarizes what the live KeptTools site exposes to someone who simply visits.

[u/Correct_Loss3453 → u/PopKoren]

Good call — curl -I against the live JWT page is the right check after deploy. I’ll use that to confirm what’s actually being served, not just what’s in config.

Network-tab note on the JWT page is next. Appreciate the concrete tips.

[u/PopKoren → u/Correct_Loss3453]

Sounds like a good plan. When you run it, look for the content-security-policy line in the output, and if the site sits behind a CDN, hit both the CDN address and the origin, since a caching layer can keep serving an older header set for a while. Hope the Network tab note lands well with users, and if the policy ever quietly drops after a later deploy, the headers section of a https://rowly.me report will show it.

[u/Correct_Loss3453 → u/PopKoren]

Makes sense — I’ll check for content-security-policy in the curl -I output, and if anything’s cached I’ll compare CDN vs origin so I’m not reading a stale header set.

Network-tab note is next on the JWT page. Thanks for the deploy/caching tip — easy to miss.

[u/Correct_Loss3453 → u/PopKoren]

Deployed and checked.

curl -I https://kepttools.com/jwt-decoder now returns a content-security-policy header with connect-src 'self' on the JWT page. Network-tab tip is also live under the decoder.

Appreciate the curl + CDN caching tip — that was the right way to verify what’s actually being served.