Hoppscotch vs Bruno: The Open-Source API Client Showdown

I deleted Postman from my machine in March 2026. The immediate trigger was benign — an update that moved collection variables three menus deeper than they used to be — but the real reason was an accumulation of friction points that, taken individually, were minor and, taken together, had made the tool feel hostile to the way I work. The login requirement for offline use. The workspace collaborator limits on the free tier. The growing distance between the lightweight HTTP client I installed in 2018 and the API platform it had become, with mock servers, documentation generators, and monitoring dashboards I had never touched and had no interest in learning.

Two open-source alternatives kept surfacing in recommendations: Hoppscotch and Bruno. Hoppscotch pitches itself as “open source API development ecosystem” — a browser-based tool that runs collection requests, generates code snippets, and supports REST, GraphQL, WebSocket, and MQTT. Bruno pitches itself as “the open source API client that stores your collections directly on your filesystem” — an offline-first desktop application where collections are plain text files you version in Git alongside your code.

I used both for a month of daily API development: a REST API in Node.js with thirty-seven endpoints across six resource groups, and a GraphQL API with fifteen queries and mutations. Here is how they compare.

The Philosophical Divide: Browser vs. Filesystem

The deepest difference between Hoppscotch and Bruno is not about features. It is about where your API collections live and who controls them.

Hoppscotch runs in the browser. Your collections, environment variables, and request history live in the browser’s local storage by default. You can sync them to a Hoppscotch cloud account or self-host the backend, but the primary interface is the web app at hoppscotch.io. This is both Hoppscotch’s biggest strength — zero installation, works on any machine with a browser — and its biggest weakness: your API collections are trapped in browser storage unless you explicitly export them.

Bruno runs as a desktop application. Your collections are stored as plain text files in a directory on your filesystem — each request is a .bru file that looks like a simplified HTTP message. Environment variables and collection settings are also plain text files. This is Bruno’s biggest strength: your API collections are first-class files that live in your project repository, version-controlled alongside your code, and accessible from any text editor. The tradeoff is that Bruno is desktop-only — no browser-based quick access, no mobile interface, no shared workspace you can open from a colleague’s machine.

After a month, the winner for my workflow was Bruno, but the reason is specific to how I work. My API collections live in the same GitHub repository as the API server. When a developer clones the repo, they get the code and the API requests for testing. When the API changes, the collection changes in the same commit. When I review a PR, the diff shows both the code change and the corresponding request update. This workflow is impossible in Hoppscotch and effortless in Bruno — and it alone outweighs every other feature comparison.

Collection Management: How Each Tool Organizes Requests

Hoppscotch organizes requests into collections with folders and subfolders. The interface is familiar to anyone who has used Postman — a sidebar tree, drag-and-drop reordering, and the ability to run an entire collection or a single folder as a sequence. Hoppscotch also supports pre-request scripts and test scripts written in JavaScript for each request, which run before the request is sent and after the response is received.

Bruno organizes requests into collections stored as directory structures on disk. A folder in the Bruno interface is a folder on your filesystem. A collection is a directory containing .bru files. This means you can organize collections with any folder structure you want and rearrange them by moving files in your file manager or terminal. It also means you can use shell scripts to generate, modify, or validate collections — a use case Hoppscotch does not support because collections live in browser storage.

Bruno’s scripting model uses a JavaScript runtime for pre-request and post-response scripts, similar to Hoppscotch and Postman. The API is slightly different — Bruno uses its own bru global object for assertions and variable manipulation — but the mental model is the same. If you have written Postman test scripts, the transition to Bruno scripting takes about an hour of reading documentation and experimenting.

Hoppscotch’s advantage in collection management is the collaborative workspace. Multiple team members can access the same collection through a Hoppscotch cloud account, with role-based permissions and real-time updates. Bruno has no equivalent — collaboration means sharing the collection files through Git and resolving merge conflicts manually when two people edit the same request.

Environment Variables and Dynamic Values

Both tools handle environment variables, but the implementation reflects their architectural philosophies.

Hoppscotch stores environment variables in the browser (or cloud account) as key-value pairs. You can create multiple environments — Development, Staging, Production — and switch between them with a dropdown. Variables use the <<variableName>> syntax, consistent with Postman. Dynamic variables like <<timestamp>> and <<randomInt>> are built in. Environment syncing requires a Hoppscotch cloud account or self-hosted backend.

Bruno stores environment variables as JSON files in the collection directory. A typical environment file looks like this:

{
  "name": "Development",
  "variables": {
    "baseUrl": "http://localhost:3000",
    "apiKey": "dev-key-do-not-use-in-production",
    "userId": "usr_test123"
  }
}

This approach means environments are also version-controlled. You can check in a development environment with localhost URLs and exclude the production environment from the repository (or store it encrypted). Bruno supports variable interpolation with {{variableName}} syntax, and environment switching is a dropdown in the UI.

The filesystem-based environment approach eliminates the problem we had in Postman where environment variables drifted out of sync across team members. Because the development environment is checked into the repository, every developer gets the same configuration when they clone. The production environment stays local.

REST and GraphQL Support

Both tools support REST and GraphQL, with meaningful differences in the GraphQL experience.

Hoppscotch’s GraphQL interface is a first-class feature. You write queries in a split-pane editor with schema introspection, autocomplete, and documentation generated from the schema. Variables are defined in a separate pane, and the response renders with syntax highlighting and collapsible sections. Hoppscotch also supports GraphQL subscriptions via WebSocket, which is a feature Postman added late and Bruno does not support.

Bruno’s GraphQL support works through a dedicated body type. You write the query in the request body, define variables in a JSON block, and send the request. Schema introspection and autocomplete are not built in — you need to know your schema or reference it externally. For teams with well-documented GraphQL schemas, this is a minor inconvenience. For teams exploring a new GraphQL API or working with rapidly changing schemas, Hoppscotch’s introspection and autocomplete are a significant productivity advantage.

For REST, both tools handle the full request surface: headers, query parameters, path variables, request bodies (JSON, form data, multipart, raw), authentication (Basic, Bearer, OAuth 2.0, API key), and response viewing with syntax highlighting. The differences are in details rather than capabilities — Hoppscotch’s response viewer is slightly more polished with collapsible JSON trees, while Bruno’s response viewer renders plain text with optional syntax highlighting.

The Offline and Data Ownership Question

The most frequent criticism of Postman is the login requirement and the data living on Postman’s servers. Both Hoppscotch and Bruno address this, but in different ways.

Hoppscotch is usable without an account — your collections live in browser local storage. The risk is that clearing browser data destroys your collections unless you export them. The self-hosted backend option (Hoppscotch’s open-source server) eliminates the dependency on Hoppscotch’s cloud, but it requires infrastructure you maintain. For individuals, the export feature is the safety net: export collections as JSON files periodically and store them in your project repository.

Bruno solves the data ownership question completely. Your collections are files on your hard drive. If Bruno disappears tomorrow, you still have the files. If you want to access collections from multiple machines, you sync them through Git, Dropbox, or any file-sync tool. There is no cloud platform, no account requirement, and no infrastructure to maintain.

Which Tool Fits Which Developer

After a month of using both, the answer depends on two questions: where do you want your API collections to live, and do you need GraphQL introspection?

Choose Hoppscotch if you work on multiple machines and want browser-based access without installing anything, you need GraphQL schema introspection and autocomplete, or you want a tool that works the moment you open a browser tab on any machine. Hoppscotch is also the better choice for teams that want collaborative workspaces and are willing to self-host the backend or pay for cloud sync.

Choose Bruno if you version your API collections in Git alongside your code, you prefer files on your filesystem over browser storage, or you want the confidence that your collections are plain text files that outlast any tool. Bruno is also the better choice for individual developers who do not need team collaboration features and want zero external dependencies.

Both tools are open source and free. The switching cost is measured in minutes — install both, import a collection, and see which workflow fits your brain. You will know within a week which one you reach for when you need to test an endpoint.

FAQ