DEV Community: Abhay kumar

I Built a Collection of Free Developer Tools Because I Was Tired of Opening 10 Browser Tabs

Abhay kumar — Tue, 23 Jun 2026 07:45:20 +0000

As developers and testers, we spend a surprising amount of time doing small repetitive tasks.

Formatting JSON.
Decoding JWT tokens.
Comparing API responses.
Testing regex patterns.
Converting timestamps.
Encoding and decoding Base64 strings. None of these tasks are difficult, but constantly switching between different websites breaks focus and slows down the workflow.

A few months ago, while working on OrbitTest and testing APIs daily, I noticed that I was repeatedly opening the same set of utility websites. Sometimes I had more utility tabs open than actual project tabs.

That became the motivation behind creating a dedicated tools section on OrbitTest.

The goal wasn't to build something revolutionary.

The goal was simple:

Keep frequently used developer utilities in one place and make them fast, clean, and accessible.

Some of the tools currently available include:

JSON Formatter & Validator
JWT Decoder
Base64 Encoder / Decoder
JSON Compare Tool
Regex Tester
Timestamp Converter

- XML ↔ JSON Converter

JSON Schema Generator
Everything runs directly in the browser and is designed to be lightweight and easy to use.

One thing I've learned while building products is that not every feature has to be a massive innovation. Sometimes removing small daily frustrations creates the most value.

If you're a developer, tester, QA engineer, or anyone working with APIs, I'd love to know:

What's the developer tool you use almost every day?

You can explore the tools here:

https://www.orbittest.dev/tools

Feedback is always welcome.

Why "Log in with Google" never sees your password (PKCE, explained)

Abhay kumar — Tue, 23 Jun 2026 06:59:35 +0000

Ever wondered how "Log in with Google" works without the app ever touching
your password? That's OAuth 2.0 — and on mobile apps and SPAs, the piece that
makes it safe is PKCE (Proof Key for Code Exchange).

The problem PKCE solves: a public client (a mobile app or SPA) can't keep a
secret. So an attacker who intercepts the authorization code could exchange it
for a token.

PKCE fixes this with a simple trick:

The app generates a random "code verifier"
It sends a hashed version (the "code challenge") when starting login
To redeem the code, it must present the original verifier

An intercepted code is useless without the verifier that only the real app has.

I broke down the whole flow step by step — what each value does and the exact
attack it prevents:

👉 https://www.orbittest.dev/blog/oauth-authorization-code-flow-pkce

Are you using PKCE in your SPA/mobile auth today?

Stop waiting for the backend — mock any API in seconds

Abhay kumar — Tue, 23 Jun 2026 06:57:16 +0000

Frontend devs lose so much time waiting on backend APIs that aren't ready.

The usual "fix" — hand-writing JSON mock files and wiring up routes — just
trades one chore for another, and the mocks drift from reality over time.

A faster pattern: record a real API response once, then replay it from a local
mock server. Your app points at http://127.0.0.1:4010 instead of the real
backend and keeps working — even offline, even when the backend is down.

Great for:
• Building UI before the API exists
• Stable, repeatable test data
• Demos that don't depend on the network
• Avoiding third-party rate limits during dev

I wrote up the record-once/mock-instantly approach (with a short demo):

👉 https://www.orbittest.dev/blog/ghost-mock-server-local-api-mocking

How do you handle "API isn't ready yet" on your team?

Is your JWT encrypted? (No — and that trips up a lot of devs)

Abhay kumar — Tue, 23 Jun 2026 06:50:07 +0000

Common misconception: "JWTs are encrypted, so I can store data in them."

Reality: a standard JWT's header and payload are only Base64-encoded —
fully readable by anyone. Paste one into any decoder and the claims fall right
out. The signature proves the token wasn't tampered with; it does NOT hide
the contents.

So: never put secrets in a JWT payload.

While we're clearing up auth confusion, three things that look similar but
aren't:
• Encoding (Base64) → representation, reversible, no key
• Encryption (AES) → protection, reversible with a key
• Hashing (SHA-256) → one-way, can't be reversed (why passwords are hashed)

I wrote a from-scratch guide to API authentication — Basic Auth, API keys,
bearer tokens, JWT, and OAuth 2.0 — plus how to actually test each one:

👉 https://www.orbittest.dev/blog/api-authentication-oauth-jwt-tokens

What auth method does your current project use?

401 vs 403, 400 vs 422 — the status codes everyone mixes up

Abhay kumar — Tue, 23 Jun 2026 06:47:58 +0000

Quick quiz — which status code is correct?

• You're not logged in → ?
• You're logged in but not allowed → ?
• The JSON is malformed → ?
• The JSON is valid but the email is invalid → ?

Answers:
• 401 Unauthorized → "who are you?" (missing/invalid auth)
• 403 Forbidden → "I know you, you still can't"
• 400 Bad Request → malformed request
• 422 Unprocessable → valid request, failed validation

The #1 mistake I see: returning 200 OK for a login failure, or 500 for bad
user input. Both break monitoring and make debugging miserable, because the
first digit of a status code is supposed to tell you whose fault it is:

2xx = success · 3xx = go elsewhere · 4xx = your fault · 5xx = server's fault

I put together a complete guide with real examples, a cheat-sheet table, and a
testing checklist for every category:

👉 https://www.orbittest.dev/blog/http-status-codes-explained

What's the most misused status code you've seen in the wild?

A passing 200 OK doesn't mean your API didn't break

Abhay kumar — Tue, 23 Jun 2026 06:44:48 +0000

Here's a bug that ships to production constantly, with every test green:

The backend renames one field.

Before:
{ "subscription": "Premium" }

After:
{ "plan": "Premium" }

✅ Endpoint returns 200
✅ Unit tests pass
✅ Build is green
❌ The mobile app reads response.subscription → undefined → crash

Functional tests check that a response came back. They don't check its
shape. That gap is exactly what contract testing closes — it verifies the
response still matches what consumers expect (fields, types, structure).

A few rules that prevent most of these incidents:
• Never rename or remove a field without versioning
• number → string is a breaking change, even if your language coerces it
• Add new fields; don't replace old ones
• Run schema checks in CI, not just on your laptop

I wrote a full breakdown — contract vs integration testing, consumer-driven
contracts, the 5 most common breakages, and how to catch drift automatically:

👉 https://www.orbittest.dev/blog/contract-testing-explained

How does your team catch breaking API changes today? Curious what's working.