DEV Community: Roxroy

Stop Rewriting the Same Dev Helpers: Build a Browser Toolbelt Instead

Roxroy — Tue, 30 Dec 2025 18:44:00 +0000

For a long time, my dev life looked like this:

Open editor.
Open docs.
Google “online JSON formatter” for the fifth time that week.
Write another tiny helper script I knew I had somewhere, but couldn’t find.

None of these tasks were hard:

Format or validate JSON
Convert CSV ↔ JSON ↔ XML
Generate test data
Convert time zones
Decode some weird token or Base64 blob

But they were constant. Death by a thousand tiny helpers.

At some point I realised my problem wasn’t skill. It was that I treated every small task as a one‑off, instead of part of a repeatable workflow. So I stopped trying to be a hero and built myself a browser toolbelt instead.

What changed for me

Once I treated these chores as a system, a few things shifted:

I cut my “yak shaving” time by roughly 60–70%.
The little 5–10 minute detours started to disappear.
I went from many small context switches to a few predictable ones.

None of this shows up on a project plan, but it shows up in how tired your brain feels at 3 p.m.

This post walks through how I built that toolbelt, and how you can build your own with whatever tools you prefer. I did end up turning my own setup into a public toolbox at CodersTool, but the ideas here work even if you never visit the site.

A simple rule: refuse “one‑off” scripts for repeat work

I use one rule now:

If a task is repetitive, mechanical, and easy to get wrong,

I try not to solve it with a brand‑new script.

Instead of opening a scratch file, I ask three questions:

Have I solved this before?
Is there a stable tool that already does this?
Does this really need to live in the repo?

Often the answer is “no, I just need a reliable helper.” That’s where the browser toolbelt comes in.

From random tabs to a deliberate toolbelt

For years my “toolbelt” was just search history:

format json online
csv to json
utc to est converter
url decode online

Every session: same searches, slightly different sites, new pop‑ups and layouts. Two problems:

Behaviour wasn’t consistent.
I never built muscle memory.

So I did something boring but effective:

Picked one tool per repeated chore.
Bookmarked it in a Dev Toolbelt folder.
Used that same tool every time.

That was the turning point. Once the folder existed, adding and pruning tools became natural.

The core categories in my browser toolbelt

Your work will be different, but these categories gave me the best return.

1. JSON and API helpers

If you touch APIs, JSON is probably your main friction point. I rely on three things:

A formatter/validator so I can actually read payloads.
A way to diff two JSON blobs.
Converters between JSON and CSV or XML.

You can cover this with:

Your IDE formatter
CLI tools like jq
One trusted online formatter and converter

The key is to stop hunting and use the same few tools each time.

2. Test data and fixtures

I used to “test” with test@test.com and John Doe and be surprised when real data broke everything.

Now I treat realistic test data as a first‑class tool:

Faker‑style libraries for code
Simple generators for CSV / JSON lists
A shared sample dataset I can reuse

The workflow is simple: generate, export, import, re‑use. The more realistic your test data, the fewer weird production bugs you get.

3. Time zones and date math

Time zones can eat entire afternoons. I mix:

Language features and libs
MDN or official docs
One friendly converter for sanity checks

I never try to do timezone math in my head anymore. I push it through the same tiny set of tools every time.

4. Encodings and “what is this string?”

I keep one place for:

Base64
URL encoding/decoding
HTML entities
Quick hash checks

You can do most of this with your standard library or openssl. I still like having a familiar browser tool for quick checks, especially when I’m away from my main machine.

Keep it safe

Browser tools are powerful, but they need guardrails:

Never paste production secrets or live customer data into random sites.
Prefer tools that clearly say they process data in the browser.
For sensitive workflows, consider self‑hosted or in‑house tools.

If it would be awkward to explain in a post‑mortem, it doesn’t belong in a public tool.

Where AI fits in (and where it doesn’t)

Today we also have AI helpers like Copilot and ChatGPT. They are great for:

Sketching one‑off scripts
Exploring unfamiliar APIs
Explaining confusing stack traces

But they are not a full replacement for a toolbelt:

AI can be confident but wrong.
It may use outdated or insecure patterns.
Results can change from run to run.

A small, deterministic toolbelt still wins for:

Quick format / convert / validate jobs
Reproducible workflows you can share with the team
Situations where you cannot paste data into an AI system

I use AI around the toolbelt, not instead of it.

When your toolbelt isn’t enough

Not everything belongs in a browser tool. Some signs you need a different approach:

The task must run in CI or on every deploy.
The logic is specific to your business rules.
You need state, history, or heavy performance work.

Those problems deserve proper code, tests, and review. For me, the toolbelt is for stateless, repetitive, mechanical tasks.

Build your own in 20 minutes

If you want to try this, here is a quick starting plan:

List your top five recurring annoyances.
For each one, pick a single helper you like.
Create a Dev Toolbelt bookmark folder.
Add those links and pin the folder.
For one week, reach for the toolbelt before writing a new helper.

Optional extras:

Add custom search keywords in your browser.
Pin a “toolbelt” tab you always keep open.
Share the list with your team and invite suggestions.

Start with three solid tools, not thirty. Add more only after you feel the same pain a few times.

If you’re curious what my own browser toolbelt looks like in a more concrete, tool-by-tool way, the canonical, link-heavy version of this idea lives here:
👉 https://www.coderstool.com/blog/computer-programming-made-easier

Common pitfalls

A few mistakes I ran into:

Trying to build a “perfect” toolbelt in one sitting
Re‑implementing tools that already exist and work well
Making everything depend on personal quirks no one else understands
Never pruning old or broken tools from the folder

Keep the bar simple: does this tool save me time, reliably, in real work? If not, it goes.

A tiny maintenance habit

Once a quarter, I spend ten minutes in the bookmark folder:

Remove tools I no longer use.
Replace anything that feels slow or sketchy.
Add one or two helpers that proved useful in the last few months.

That little cleanup keeps the toolbelt feeling light instead of bloated.

Over to you

That’s how I went from random tabs and throwaway helpers to a small browser toolbelt that quietly saves me hours a month.

I’m curious:

What is one tool you can’t live without in your daily dev work?
Do you keep a toolbelt like this, or is everything still hiding in search history and old repos?

Share your essentials in the comments. I’d love to steal a few good ideas for my own setup.

How to Add a security.txt File to Your Website in 5 Minutes (With a Generator)

Roxroy — Wed, 03 Dec 2025 15:53:00 +0000

If you’re running a website in 2026, you probably care about security.

You might have HTTPS, HSTS, CSP, maybe even a bug bounty program. But there’s a tiny text file most sites still miss:

/.well-known/security.txt

It’s a simple file that tells security researchers how to contact you if they find vulnerabilities on your site.

In this post, I’ll explain:

What security.txt is (in human words)
Why it matters even if you don’t run a big security team
What goes inside the file
How to generate one in a couple of minutes using a browser-based tool
How to deploy it on common setups (static site, Laravel/PHP, .NET/IIS, etc.)

No security team required. Just you, a text file, and a few minutes.

What is `security.txt`?

security.txt is a proposed standard (RFC 9116) for publishing security contact information for your website.

The idea is similar to robots.txt:

robots.txt → tells search engines how to crawl your site
security.txt → tells security researchers how to report vulnerabilities

It normally lives at:

/.well-known/security.txt

on your main domain. For example:

https://example.com/.well-known/security.txt

Inside that file, you list things like:

Who to contact (email or URL)
A link to your security policy
Optional: your PGP key, acknowledgements page, hiring info, etc.

So when someone finds a bug and wants to report it responsibly, they don’t have to guess. They just go to that URL and follow the instructions.

Why should you care as a “normal” developer?

You don’t need to be a security engineer to benefit from security.txt.

1. It reduces friction for responsible disclosure

Many security issues go unreported because people don’t know where to report them:

No security@ email address
No bug bounty program
No clear disclosure policy

A security.txt file says:

“If you find something, here’s exactly how to tell us.”

That alone can be the difference between a quiet, responsible report and an angry social media thread.

2. It shows you take security seriously

Even if you’re a small SaaS, indie project, or side project, adding security.txt sends a signal:

You’ve thought about security, at least to the point of defining a contact and a process.
You’re open to hearing from researchers and power users.

You don’t need a massive program. A simple line like:

Policy: https://example.com/security-policy
Contact: mailto:security@example.com

is enough to look much more mature than “no info at all”.

3. It’s cheap “security hygiene”

Some security improvements are complex and time-consuming.

This one is not.

A small text file
Served over HTTPS
Updated once in a while when contacts change

It’s one of those “10 minutes now, potential life saver later” tasks.

What goes inside a `security.txt` file?

The standard defines several fields. You don’t need all of them, but here are the most common ones:

Required-ish (strongly recommended)

Contact – How to reach you about security issues

  Contact: mailto:security@example.com
  Contact: https://example.com/security-contact

Expires – When this file should be considered out of date

  Expires: 2026-01-01T00:00:00Z

Very useful

Policy – Your security/vulnerability disclosure policy

  Policy: https://example.com/security-policy

Acknowledgments – Where you thank researchers (if you have a hall of fame)

  Acknowledgments: https://example.com/security-acknowledgments

Encryption – Public key for sending encrypted reports

  Encryption: https://example.com/pgp-key.txt

Hiring – If you’re hiring for security roles

  Hiring: https://example.com/careers

Canonical – The canonical URL of this security.txt

  Canonical: https://example.com/.well-known/security.txt

You can also add comments with #:

# Security contact for Example Corp
Contact: mailto:security@example.com
Policy: https://example.com/security-policy
Expires: 2027-01-01T00:00:00Z

That’s it. It’s just a structured text file.

The manual way vs. the generator way

You can create a security.txt file by hand:

Read the RFC (or various blog posts)
Decide which fields to use
Copy/paste some examples
Try not to mess up the syntax
Remember to set a valid future Expires date
Save the file, move it to the right path, deploy, test…

It’s not rocket science, but it’s also the sort of thing you’ll probably do once and forget how you did it next year when you need to update it.

That’s why I prefer using a generator.

Using a browser-based `security.txt` generator

There are several generators out there. I built one into CodersTool because I kept needing simple “one-off” web utilities while working on various SaaS projects.

The flow is basically:

Fill out a small form in your browser
Get a valid security.txt snippet
Download or copy the text
Drop it into your site at /.well-known/security.txt

No login, no project setup, no CLIs.

Example workflow (CodersTool-style)

You can follow this even if you use a different generator – the steps are the same.

Open the generator
Go to the security.txt generator on CodersTool.
Fill in the key fields

Contact – Most people use a dedicated mailbox like security@yourdomain.com
Policy – If you don’t have a detailed policy, even a short page explaining “please email us, don’t publicly disclose immediately” is better than nothing.
Expires – Pick a date 6–12 months in the future, so you’re forced to review it periodically.
Optional: Acknowledgments, Encryption, Hiring, Canonical.

Generate the file The tool will spit out a security.txt that looks something like:

   # security.txt for Example SaaS
   Contact: mailto:security@example.com
   Policy: https://example.com/security-policy
   Acknowledgments: https://example.com/security-acknowledgments
   Expires: 2027-01-01T00:00:00Z
   Canonical: https://example.com/.well-known/security.txt

Copy + save locally Save it as security.txt on your local machine.

Next step: deploy it.

Deploying `security.txt` on different kinds of sites

The goal is always the same:

Serve the file from https://yourdomain.com/.well-known/security.txt

How you get it there depends on your stack.

1. Static site / GitHub Pages / plain hosting

If your site is just static HTML/CSS/JS:

Create a folder called .well-known at the root of your site:

   /your-site-root/
     index.html
     ...
     /.well-known/
       security.txt

Put your generated security.txt inside it.
Deploy / upload as you normally would.

Test it:

https://yourdomain.com/.well-known/security.txt

You should see your text file in the browser.

If you’re using a static site generator (Hugo, Jekyll, etc.), you can usually add .well-known/security.txt to your public/dist output via a static files folder.

2. Laravel / PHP apps

For a typical Laravel app:

Option A – Serve it as a static file

Create public/.well-known/ if it doesn’t exist.
Add your security.txt inside:

   /public/
     index.php
     ...
     /.well-known/
       security.txt

Laravel will happily let the web server serve this file directly.

Option B – Route-based (if you really want it dynamic)

If you prefer to generate it dynamically (e.g., from config or DB), you can add a route:

// routes/web.php
Route::get('/.well-known/security.txt', function () {
    $content = <<<TXT
# security.txt for Example SaaS
Contact: mailto:security@example.com
Policy: https://example.com/security-policy
Expires: 2027-01-01T00:00:00Z
TXT;

    return response($content, 200)
        ->header('Content-Type', 'text/plain');
});

But honestly, a static file is usually enough.

3. ASP.NET / IIS apps

For .NET apps hosted on IIS:

In your site’s root folder, create a .well-known directory.
Drop security.txt into it.
Ensure IIS is configured to serve .txt from that path (it usually is by default).

File structure:

/wwwroot/
  web.config
  ...
  /.well-known/
    security.txt

If you’re running ASP.NET Core with Kestrel + reverse proxy:

Put .well-known/security.txt into wwwroot, or
Map a route in your app to return the text file.

4. Behind a CDN or reverse proxy

If you sit behind something like Cloudflare, Fastly, etc.:

Make sure the upstream origin serves /.well-known/security.txt.
Check that your CDN isn’t blocking or rewriting that path.
If your CDN has its own security.txt feature, decide whether to:
- Use theirs directly, or
- Use your origin security.txt and let the CDN just pass it through.

In many cases, you can still generate the content using a tool and then paste it into whatever config your CDN expects.

How to verify your `security.txt` file

Once you’ve deployed, check:

Direct browser test Open:

   https://yourdomain.com/.well-known/security.txt

in your browser and confirm:

It’s accessible over HTTPS
It’s not being redirected somewhere weird
The content matches what you generated

Check headers Use your browser dev tools or curl:

   curl -I https://yourdomain.com/.well-known/security.txt

Look for:

HTTP/2 200 (or similar success code)
content-type: text/plain (ideal, though not strictly mandatory for humans)

Use an online validator There are validators that will:

Fetch your security.txt
Check required fields
Flag issues like invalid Expires dates or unreachable URLs

(Just search “security.txt validator” and plug in your domain.)

Common mistakes to avoid

A few gotchas that pop up a lot:

Wrong path
https://example.com/security.txt is not the standard path.
Use https://example.com/.well-known/security.txt.
No HTTPS
The file should be available over HTTPS. Serving it only over HTTP is discouraged.
Expired Expires date
If the Expires value is in the past or very soon, tools may treat your file as stale.
Unmonitored email address
Don’t point Contact to an inbox nobody checks. Even if you can’t reply to every report, someone should at least see them.
Invalid Contact
Ensure the email address you list (security@ or admin@) actually goes to a real inbox that is monitored.
Forgetting to update when things change
If your security contact moves, or your policy URL changes, update the file. That’s one reason having a generator handy is nice — you can recreate a clean file quickly.

Where to go from here

You don't need a SOC 2 audit or a dedicated CISO to take security seriously. You just need to be reachable.

If you own or manage a website, adding security.txt is one of those small, high-leverage tasks:

It takes minutes.
It helps people help you.
It signals that you give a damn about security.

You can:

Open a security.txt generator (like the one on CodersTool).
Fill in your contact, policy, and expiry.
Save it as /.well-known/security.txt on your site.
Verify it in the browser and with a quick validator.

Then you can forget about it… at least until your next Expires date reminder.

If you haven't created one yet, head over to the CodersTool Generator, create your snippet, and push it to production today.