DEV Community: Nishant Gohel

Stop Pasting Sensitive API Payloads into Random Websites. Here’s a Better Way.

Nishant Gohel — Fri, 06 Nov 2026 11:47:17 +0000

If you are an SDET or backend developer writing API tests, you know the drill: an endpoint returns a massive, unformatted JSON payload. To figure out why your RestAssured or Cucumber assertion failed, you copy the response, open a new tab, search for a JSON formatter, and paste it in.

Then you realize you just pasted customer data and internal authentication tokens into a random, ad-supported server.

I built Captain JSON under the Pirates of Bugs initiative to eliminate this exact workflow friction and keep your data strictly on your machine.

What is Captain JSON?
Captain JSON is a local-first browser extension designed specifically for the daily workflows of quality engineering specialists and API developers. It runs 100% offline, meaning your payloads never leave your browser.

Core Developer Features
JSONPath Generator & Evaluator: Stop guessing the path to a nested array element. Click any node in your JSON tree to instantly generate the exact JSONPath expression needed for your automation frameworks.

JSONL File Processing: Log files formatted in JSON Lines (JSONL) often crash standard text editors. Captain JSON processes and lets you inspect them smoothly right in the browser.

Side-by-Side Comparison: Paste two payloads to instantly highlight schema mismatches, missing keys, or altered values—crucial for regression testing endpoint updates.

Zero Server Transmission: The formatting, validation, and parsing happen entirely locally.

Stop Context-Switching
The goal is a single-tool workflow. You shouldn't need three different web utilities to format a payload, write a JSONPath, and compare environments.

You can grab the extension from the Chrome Web Store here: https://piratesofbugs.com/captain-json

Try it out on your next API test run, and let me know what features you want to see next as we expand the Pirates of Bugs toolset!

10 Chrome Extensions Every Software Engineer Should Know

Nishant Gohel — Fri, 23 Oct 2026 05:07:38 +0000

A tester can spend an hour investigating a bug that a good browser extension could have helped explain in minutes. And still, plenty of teams treat extensions as optional extras instead of tools that belong in their daily testing workflow.

The problem starts with the phrase "testing tool."

What does it actually mean? A tool that helps you find an element? Inspect an API response? Capture a visual defect? Or give a developer enough evidence to reproduce a bug without scheduling another meeting?

These are different jobs. Treating them as interchangeable is how testers end up with 25 extensions installed and still struggle to explain a broken checkout flow.

A useful extension should help you answer a specific question about the application. Here are 10 worth considering.

1. Captain Octopus - Capture the Story Behind a Bug

A screenshot can show a broken page. It rarely explains what happened before the page broke.

Did the tester click the wrong button? Did an API request fail? Was there a JavaScript exception? Did the problem occur after a particular navigation?

Captain Octopus, from Pirates of Bugs, focuses on capturing the evidence behind a browser bug report.

It records browser interactions and creates a replayable session with reproduction steps, screenshots, console errors and exceptions, and network details for fetch and XHR requests. The resulting report helps connect the actions to the evidence, rather than leaving the developer to reconstruct the sequence from a paragraph of text.

Why does that matter?

Because "Not able to reproduce" is a frustrating dead end when the original report doesn't contain the information needed to investigate.

Captain Octopus is also designed around local-first reporting. Its reports remain in the browser unless explicitly exported, with sensitive data redacted before storage.

Best for: Exploratory testing, defect reporting, debugging browser issues, and sharing reproducible evidence with developers.

Product: Pirates of Bugs https://piratesofbugs.com/

2. Captain JSON - Make API Responses Easier to Investigate

API testing produces a lot of JSON. Some responses are small enough to read comfortably. Others look like someone emptied an entire database into a single line and called it a day.

When a response contains deeply nested objects, repeated fields, or large arrays, finding the actual problem becomes tedious.

Captain JSON is a browser-based JSON toolkit built for developers and testers who work with structured data.

Its toolkit includes JSON formatting and validation, JSON comparison, JSONPath generation, table conversion, escaping, and conversion between formats such as JSON, XML, YAML, CSV, and Properties. It also includes capabilities such as JSONL processing and JWT inspection.

Imagine comparing two API responses after a deployment. The request succeeds, the status code is 200, but one nested field has changed or disappeared. A readable response and a focused comparison make that discrepancy easier to investigate.

A successful HTTP response does not guarantee a correct response.

Best for: API testing, response inspection, test-data preparation, JSON debugging, and working with structured payloads.

Product: https://www.piratesofbugs.com/

3. Captain Spyglass - Inspect the UI Instead of Guessing

A button looks slightly misaligned. A form field has too much spacing. A component doesn't match the design specification.

Someone reports it as a UI bug. Someone else opens the page, looks at it, and says it seems fine.

Now the discussion is about opinions instead of measurements.

Captain Spyglass is an alignment inspection extension from Pirates of Bugs. It helps testers inspect element dimensions, spacing, and alignment by hovering over elements, with Figma-based validation as part of its workflow.

Instead of saying, "This button looks a little off," you can investigate the actual layout and compare it against the intended design.

That is a much better starting point for a defect report.

Best for: UI testing, visual defect investigation, spacing checks, and validating implementations against Figma designs.

Product: Pirates of Bugs

4. SelectorsHub - Stop Guessing Your Locators

Automation scripts often fail because a locator no longer identifies the intended element. Sometimes the locator was fragile from the beginning.

SelectorsHub helps testers inspect and create locators for web elements, including XPath and CSS selectors. It also supports selector verification and other locator-generation workflows.

Suppose a page contains three buttons labelled "Continue." Which one does your test need? A locator that happens to work today isn't necessarily a locator you can trust after the next UI change.

Use SelectorsHub to investigate the DOM, test candidate selectors, and understand why a locator matches an element.

Do not blindly copy the first generated XPath into your framework. A tool can generate a locator; it cannot decide whether that locator represents the right business action.

Best for: Selenium, Playwright, and other web automation workflows that depend on reliable element identification.

Website: https://selectorshub.com/

5. Requestly - Change Requests Without Changing Application Code

Sometimes a test scenario depends on a request header, a modified API response, or a request that needs to be redirected. Changing application code just to investigate that behaviour is unnecessary overhead.

Requestly provides tools for modifying HTTP requests and responses, including headers and redirects, depending on the rules and features available in your setup.

For example, you can investigate how an application behaves when a custom header is changed or when a request is redirected to a different endpoint. This can help reproduce certain integration issues without waiting for a backend code change.

Use it carefully. Request modifications can affect application behaviour in unexpected ways. Keep your rules scoped to the intended test environment, and avoid exposing authentication tokens or sensitive data.

Best for: Request and response modification, header testing, redirects, and controlled API debugging.

Website: https://requestly.com/

6. Postman Interceptor - Connect Browser Activity With API Investigation

A web application can make several API requests while you perform a single action. Understanding those requests can be the difference between reporting a symptom and identifying a useful lead.

Postman Interceptor helps capture browser network requests and synchronise supported browser cookies with Postman, making it easier to investigate requests from an authenticated session.

Consider a user who can open an account page but cannot update their profile. The visible error is only one piece of evidence. The request, headers, cookies, response status, and response body may reveal more.

Instead of manually recreating every request from scratch, you can use captured information to continue the investigation in Postman.

Remember that captured traffic may contain authentication tokens, personal information, and other sensitive data. Use appropriate test accounts and follow your team's security rules.

Best for: API debugging, authenticated web sessions, and investigating browser-to-backend communication.

Website: https://www.postman.com/

7. Lighthouse - Investigate Performance and Page Quality

A page can function correctly and still provide a poor experience.

It might load slowly, have accessibility problems, or contain performance issues that are invisible during a quick functional check.

Lighthouse audits web pages for areas including performance, accessibility, SEO, and adherence to web best practices. It is available through Chrome DevTools as well as other supported interfaces.

Run an audit on a page that feels slow or behaves differently after a change. Use the report to identify potential problems and decide what deserves deeper investigation.

But don't turn the Lighthouse score into a release decision by itself. Results can vary with the environment, and a high score does not prove that the application works correctly.

A green report cannot tell you whether a customer can complete the payment journey.

Best for: Initial performance investigation, accessibility checks, and identifying web-quality issues.

Website: https://developer.chrome.com/docs/lighthouse/overview/

8. axe DevTools - Find Accessibility Problems Earlier

A page can pass its functional tests while remaining difficult for people with disabilities to use.

Missing accessible names, contrast problems, and incorrect accessibility attributes can affect how users interact with an application.

axe DevTools provides accessibility testing capabilities that help identify potential issues in web interfaces.

For testers, it adds another layer to UI validation. You can investigate whether controls expose useful accessible names, whether common accessibility rules are being violated, and which findings need further review.

There is one catch: automated accessibility checks cannot identify every accessibility problem. Keyboard usability, meaningful focus behaviour, and real assistive-technology interactions still need appropriate manual testing.

Use the extension to find problems, not to declare the entire application accessible.

Best for: Accessibility audits, web UI validation, and finding common accessibility violations.

Website: https://www.deque.com/axe/devtools/

9. Wappalyzer - Understand What You're Testing

Sometimes you inherit a web application with limited documentation. Before investigating a defect, it helps to understand which technologies the page appears to use.

Wappalyzer identifies technologies used by websites, including detectable frameworks, content management systems, analytics tools, and other technologies.

This information can provide useful context when planning tests or investigating a compatibility problem.

For instance, knowing that a page uses a particular frontend framework may help guide further debugging. Identifying an analytics or tag-management tool may also help explain unexpected network activity.

But technology detection is not a security audit, and it does not reveal the complete application architecture. Treat the result as a starting point for investigation, not proof of how the system is built.

Best for: Initial technology discovery, exploratory testing, and gathering context about unfamiliar web applications.

Website: https://www.wappalyzer.com/

10. Screenshot with URL - Give Developers Something They Can See

A defect report says the navigation menu overlaps the page heading.

The developer opens the application. The overlap is gone.

The tester tries again. It returns.

The bug report now has three comments and no screenshot.

Awesome Screenshot provides browser-based screenshot capture, annotation, and screen-recording capabilities. Depending on the available features and permissions, testers can capture part of a page or a longer page and add visual explanations.

A marked screenshot can quickly show the affected element, the unexpected behaviour, and where the developer should look.

Screen recordings can help explain issues involving transitions or interactions that a static image cannot capture.

Still, a screenshot alone cannot explain a failed network request or a JavaScript exception. Pair visual evidence with technical details when the defect requires them.

Best for: Visual defect reports, annotation, and sharing browser behaviour with developers.

Website: https://selectorshub.com/screenshot-with-url/

Which Extensions Should You Install First?

There are several reasonable ways to choose browser extensions. Each has a limitation.

"Install everything that might be useful."

This sounds harmless. Extensions can save time, so why not install every promising tool?

Because every additional extension adds another permission set, another interface, and potentially another source of interference or maintenance. A crowded toolbar doesn't automatically make a tester more effective.

Install tools that solve recurring problems, not tools you might use once next year.

"One extension should handle everything."

Convenience is a fair goal. Switching between tools can interrupt an investigation.

But JSON inspection, visual alignment, accessibility auditing, and reproducible bug capture solve different problems. Expecting one extension to handle all of them well is like expecting your API client to replace your test runner, defect tracker, and browser.

Choose by task.

"The best tools are the ones everyone already knows."

Established tools deserve their reputation when they solve the problem well. Familiarity also makes adoption easier.

But familiarity alone is a poor selection criterion. A tester who repeatedly struggles to reproduce defects needs a different tool from an automation engineer who spends the day debugging XPath locators.

Pick the tool that addresses the actual bottleneck.

And when a bug reaches a developer, send evidence that answers the next question before anyone has to ask it.

Make the problem reproducible. Make the data readable. Make the visual defect measurable.

Then get back to testing.

This Fact About Developer Tools May Surprise You: The Work Is the Switching

Nishant Gohel — Tue, 20 Oct 2026 05:21:24 +0000

My teammates used to struggle to find the right tools. They bookmarked one website for JSON formatting, another for validation, another for comparison, and a few more for whatever problem showed up that week.

The bookmarks kept growing. Finding the tool became a task of its own.

We called this productivity.

I think we were measuring the wrong thing.

What Do We Mean by "Having the Right Tools"?

Developers love tools. I do too. A good tool saves time, removes repetitive work, and lets me focus on solving the actual problem.

But somewhere along the way, we confused having access to tools with having an efficient workflow.

How many tools does a developer need to format and inspect a JSON response? The honest answer is that it depends on the job. But if every small operation requires a different website, a new browser tab, and another round of copy-paste, something has gone wrong.

The problem isn't the number of tools alone. It's the friction between them.

And that friction is easy to ignore because nobody puts "time spent finding bookmarks" on a sprint report.

Just Bookmark Everything

This is the first defence I hear in my own head. Bookmarks exist for a reason. Save useful websites, organize them into folders, and move on.

Fair enough. Bookmarks are useful.

But a bookmark solves the problem of remembering a URL. It doesn't solve the problem of remembering which tool does what, which one you trust, or which one you used the last time you faced a similar problem.

Soon, the bookmark folder becomes a museum of good intentions.

You remember saving a useful JSON validator. You vaguely remember its name. Was it in Developer Tools, Testing Utilities, or that folder you created six months ago and never opened again?

Congratulations. You're now testing your memory instead of your application.

Switching Tools Is Part of the Job

Yes, it is. No serious engineer expects one application to do everything.

I don't want a hammer pretending to be a screwdriver, a database client, and a debugger. Specialization exists for good reasons.

But there's a difference between switching tools because the task demands it and switching tools because your workflow is badly arranged.

When I need to compare two JSON responses, I want to compare them. I don't want to locate a website, open it, paste the first response, switch windows, copy the second response, paste it, inspect the differences, and then move somewhere else to validate the result.

Every transition creates another opportunity to lose focus, overwrite data, or forget what I was trying to establish.

The tool may be free. The interruption isn't.

Copy-Paste Is Not an Integration Strategy

Copy-paste is one of the most useful operations in software development. It is also an easy way to hide a broken workflow.

Consider the kind of work developers do with JSON: format a response, validate its structure, compare two versions, generate a JSONPath expression, or escape a payload before using it elsewhere.

When these operations are scattered across websites, the developer becomes the integration layer.

We move the data. We remember the sequence. We verify that the right content made it to the right destination.

The browser becomes a collection of disconnected workbenches, and the engineer becomes the person carrying parts between them.

That's a remarkably expensive architecture for something we call a productivity improvement.

The Security Question Nobody Wants to Interrupt the Workflow With

There's another problem with sending data from one online tool to another: what exactly are you pasting?

A sample JSON payload may be harmless. A real API response might contain customer information, internal identifiers, authentication details, or other sensitive fields.

Not every online tool handles data the same way. Before pasting real data into any external service, I want to understand where it goes, how it's processed, and whether it's retained.

A clean interface doesn't establish trust. A free service doesn't automatically make the data safe.

And when a developer is juggling several websites just to complete a small task, security checks can become one more thing that gets skipped.

Convenience should never require blind trust.

Why I Built Captain JSON

This is the kind of friction that made me think differently about developer utilities.

Captain JSON brings common JSON tasks together in one place. Instead of hunting through bookmarks for separate utilities, developers can use features such as JSON formatting, validation, comparison, JSONPath generation, and escaping within a dedicated toolkit.

The point isn't to replace every developer tool on the internet. That's a ridiculous ambition, and I have better things to do.

The point is to remove unnecessary movement from a workflow that should be straightforward.

I want developers to spend less time finding the right utility and more time understanding the data in front of them.

Of course, no single tool eliminates every context switch. And a dedicated toolkit still needs to earn trust through its actual data-handling practices. Those details matter as much as the feature list.

But we should at least stop pretending that a browser full of bookmarks is a sign of engineering maturity.

Stop Optimizing the Wrong Thing

Look at your team's workflow. Notice how often people leave their primary task to find a small utility. Pay attention to the copying, the searching, and the repeated steps that everyone has quietly accepted.

Then remove the unnecessary ones.

Keep frequently used utilities easy to find.
Group related operations into a workflow that makes sense.
Check data-handling practices before using external tools with sensitive payloads.
Stop treating every extra browser tab as harmless.
Choose tools that reduce interruptions, not merely tools that add features.

And if your team needs a dozen bookmarks to perform a task that should take two minutes, don't celebrate the collection.

Fix the workflow.

Why I Built Captain JSON: A JSON Toolkit for Developers

Nishant Gohel — Wed, 30 Sep 2026 13:31:01 +0000

If you work with APIs, automation, or backend systems, you probably spend a ridiculous amount of time staring at JSON.

Pretty-printing it.
Validating it.
Comparing two responses.
Finding a JSONPath.
Converting it to another format.
Decoding JWTs.
Fixing that one missing comma. 😅

And somehow, we keep opening five different browser tools to do these simple tasks.

I faced the same problem every day as an automation engineer.

So I decided to build something I actually wanted to use.

Meet Captain JSON 🏴‍☠️

Captain JSON is a Chrome extension built for developers, testers, and anyone who works with JSON.

The goal is simple:

One place for the everyday JSON problems developers face.

Some of the features include:

🔍 JSON Viewer & Pretty Printer
⚖️ JSON Compare
✅ JSON Validator
🧭 JSONPath Generator
🌳 Tree View
🔄 JSON ↔ XML / YAML / CSV / Properties
🔐 JWT Decoder
🛠️ JSON Auto Repair
📊 JSON → Table
📝 JSONL Workbench
🔎 JQ support
🚀 Support for large JSON files

But this isn't just another developer tool I built and published.

It's the beginning of something bigger.

From Tester to Builder

I've spent years working with automation, APIs, CI/CD, cloud services and large test systems.

Eventually I started asking myself:

What if we built the tools that testers and developers actually need?

That question led to Pirates of Bugs.

We're building a collection of developer and testing tools designed around real problems we encounter while working with software.

Captain JSON is the first one we're pushing seriously.

Why Chrome Extension?

Because developers already live in their browser.

When an API response opens with thousands of lines of JSON, the last thing I want to do is:

Copy → open another website → paste → format → copy again.

I wanted the workflow to be closer to:

Open → Inspect → Fix → Continue working.

That's the experience I'm trying to build.

I'm Building This in Public

Captain JSON is still evolving.

I'm learning everything beyond engineering too:

Product development
UX
Chrome Web Store optimization
SEO
Marketing
Community building
Distribution
And, apparently, how difficult it is to get people to install something you've spent months building. 😅

The interesting part is that building the product was only half the challenge.

Getting it into the hands of developers is the other half.

So I'm going to experiment with different approaches and share what I learn along the way.

If you're a developer, tester, API engineer, or someone who works with JSON regularly, I'd love to hear from you.

What JSON-related problem wastes the most time in your daily workflow?

Maybe that becomes the next feature Captain JSON builds.

🏴‍☠️ Hunt Bugs. Find Treasure.

— Nishant
Pirates of Bugs