DEV Community

Cover image for Stop Rewriting the Same Dev Helpers: Build a Browser Toolbelt Instead
Roxroy
Roxroy

Posted on • Originally published at coderstool.com

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

#productivity #tooling #webdev #automation

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:

  1. Have I solved this before?
  2. Is there a stable tool that already does this?
  3. 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:

  1. List your top five recurring annoyances.
  2. For each one, pick a single helper you like.
  3. Create a Dev Toolbelt bookmark folder.
  4. Add those links and pin the folder.
  5. 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.

Top comments (0)