When a response from an API—an interface that lets software request data or services from another system—looks wrong, a page stops working, or a piece of data will not parse, developer tools help you find out why. The term covers a range of software: some tools help you write code, others run it, check it, compare changes, or inspect what a browser is doing. You do not need to install everything at once. Start with the tool that answers the question in front of you.
What counts as a developer tool?
A developer tool supports one or more steps in making and maintaining software. It might be an application on your computer, a command you run in a terminal, a feature built into your browser, or a small online utility.
Tools often work together. You might edit a file, run the project, see an error in the browser console, inspect a network request, fix the problem, and review the changes in Git. Each tool has a specific job.
Editor or IDE: where you work on code
A code editor is an application for writing and navigating files. Many editors add syntax highlighting, autocomplete, project-wide search, and extensions. Visual Studio Code, for example, introduces common editing tasks in its getting started guide.
An IDE, or integrated development environment, typically bundles a broader set of development features into one application. Depending on the IDE and language, those may include project management, running or building code, debugging, and code navigation. The boundary is not strict: a code editor with extensions may provide many features people associate with an IDE.
Choose based on the project, not the label. If you are learning a language or making a small edit, a straightforward editor may be enough. If a course or project already uses a particular IDE, its built-in run and debug features may make following along easier.
Terminal, runtime, and compiler: run the project
A terminal lets you enter commands. Developers use it to start an application, run a script, install dependencies, launch tests, or ask a version-control tool for information. Commands vary by project, so follow its setup instructions rather than copying an unfamiliar command from a different tutorial.
A runtime provides what a program needs to execute. A compiler translates source code into another form that can be run or used by a later step. The distinction can depend on the language and toolchain: some languages are commonly run through a runtime, while others are compiled before execution.
An online runner can help with a small, self-contained example when you do not have a local environment ready. You can try a short Python snippet with the site’s Python runner, or an example in its C++20 runner. There are also runners for C and Java. These are useful for experiments; they do not reproduce your project’s local setup, dependencies, or full test suite.
Git: keep track of changes
Git is a version-control system. It records changes to files so you can review what changed, save milestones, compare versions, and return to an earlier state. The Git Book explains its basic ideas and workflows.
A code-hosting platform, such as GitHub or GitLab, is a separate service that can store Git repositories online and support collaboration. Git can be used locally without publishing a project. Visual Studio Code also surfaces common Git operations, such as viewing changed files and preparing commits, through its source control tools.
One useful habit is to review the diff—the list of changes—before saving a commit. It can reveal an accidental edit or an unrelated file change while the work is still easy to correct.
Debugger and browser DevTools: investigate behavior
A debugger helps you pause a program and inspect what it is doing. Depending on the language and setup, you can step through code, check variable values, and see where execution takes an unexpected path.
For a website, browser DevTools can help answer a different set of questions. The Elements panel shows page structure and styles; the Console displays JavaScript messages and errors; the Network panel records requests and responses. Chrome’s DevTools overview introduces these panels, and its Network panel guide explains how to inspect requests.
If an API call in a web app returns unexpected data, select that request in the Network panel and inspect its status, response, and relevant headers. A successful status does not guarantee the response has the shape your code expects, and a failed request does not by itself explain the cause. Treat the details as clues, then check the code and project logs as appropriate.
Quality tools: choose the check you need
Quality tools have different jobs:
A formatter rearranges code or data into a consistent layout.
A validator checks whether something follows a format’s rules. Valid JSON, for example, may still contain values your application does not expect.
A linter looks for suspicious patterns, likely mistakes, or style issues in code.
A test runs checks written to verify particular behavior.
These checks complement each other. Formatting a file does not prove the program is correct, and passing a test does not guarantee every edge case is covered. Start with the failure you can observe, then choose the check that can answer the next question.
Small online utilities can help when the input is isolated and safe to share. The site’s Developer Tools collection includes a JSON formatter and validator, plus XML formatting and validation and YAML formatting, which offers options for indentation, wrapping, key sorting, and compact arrays.
For specific transformations, it also has Base64 encode and decode, URL encode and decode, text comparison, and case conversion. These are focused online utilities, not a local IDE, Git hosting service, browser debugger, or project test suite.
A practical workflow for a JSON or API issue
Imagine a web page displays an empty user name, even though the API request appears to succeed. Work through the issue in small steps:
Reproduce the problem. Note what you did, what you expected, and what happened instead. Check whether it affects one record or all records.
Inspect the response. If the request came from a browser page, open DevTools and find it in the Network panel. Look at the status and response body. You might see data shaped like this:
{"user":{"id":42,"active":true},"roles":["reader"]}Check the data shape. Your page may be looking for
user.name, while the response has nonamefield. If the response is difficult to scan or does not parse, format and validate a safe sample with the JSON tool. A parser error points to malformed syntax; a valid document with a missing field points to a different problem. MDN’s JSON guide explains how JSON represents structured data.
Follow the value into the code. In your editor, find where the response is read and how the name is rendered. If the value changes unexpectedly, use your debugger or an appropriate temporary diagnostic to see what the code receives.
Run the relevant check. Use the project’s own runtime and tests where possible. An online runner can help you try a short, independent language example, but it will not automatically reproduce your application’s dependencies or environment.
Review the change. Once you have a fix, inspect the diff in Git. Confirm it addresses the issue and does not include unrelated files. If the project has tests for this behavior, run them before committing.
Not every issue needs every step. A malformed JSON sample might only need a validator. A request that never reaches the server may call for Network panel details. A bug that appears only with your application’s configuration belongs in that project’s environment.
Installed tools or browser utilities?
Use installed project tools when the task depends on application dependencies, local files, credentials, configuration, or automated tests. They are also the right place to make changes that should be saved in the project and reviewed by a team.
Use a browser utility for a small, self-contained task: formatting a non-sensitive sample, comparing two short text snippets, or trying a small code example without setting up a local language environment. Check what information you are sending before using an online service, and follow your organization’s rules about where data or code may go.
Never paste secrets, access tokens, private keys, customer records, or other sensitive material into an online utility unless you have approval. Use a made-up or carefully redacted example instead. Base64 is an encoding that represents data in a different form; it does not encrypt or protect the contents. Anyone who obtains Base64 text can decode it. The format is described in RFC 4648.
Start with the next question
You do not need a large toolkit to begin. Pick one concrete question: does this data parse, what changed in this file, why did the request fail, or what value did the program receive? Then use the tool that can answer it. As your projects grow, add the editor features, terminal commands, debugging steps, and checks that solve recurring problems.