Tiger vs the field
Tiger, Postman, Bruno, Insomnia, and Hoppscotch all let you build and send HTTP requests. Where they differ is in how they store your work, what they cost, and how much they require of a server or an account. This page lays out the differences honestly.
How to read this table
Each row describes a capability that affects day-to-day workflow or team cost. Yes means fully supported in the free tier. Partial means the feature exists but is limited, requires a paid plan, or has meaningful caveats described in the note. No means the feature is absent. Information is based on publicly documented behavior as of mid-2026; always verify against each product's current pricing page before making a decision.
This table mirrors the comparison matrix in Tiger's README.md.
If you spot an inaccuracy, open an issue or pull request on GitHub.
Feature matrix
| Feature | Tiger 0.4.0 | Postman | Bruno | Insomnia | Hoppscotch |
|---|---|---|---|---|---|
| Local-first / offline | Yes - all data on disk; no network required after install | Partial - the desktop app works offline, but many features require the cloud backend | Yes - pure desktop app, no cloud dependency | Partial - desktop app is offline capable, but sync and some features need an account | Partial - self-hosted edition is fully local; hosted version requires a server |
| Plain-text & git-native storage | Yes - one .tiger file per request; diffs are human-readable |
No - collections stored in Postman's cloud or as a single opaque JSON export | Yes - one .bru file per request; similar philosophy |
No - data lives in a local SQLite database; not diff-friendly | No - collections stored in the app's own backend or browser storage |
| Works without an account | Yes - no sign-in, no registration, ever | No - account required for all tiers including free | Yes - fully offline and account-free | Partial - a local scratch project works without an account; team sync requires one | Partial - self-hosted instance can be run without external accounts; the hosted SaaS requires sign-in |
| Free / price per seat | Yes - MIT-licensed, free for individuals and teams with no seat limits | Partial - free tier exists but caps collaborators; paid plans start at $14/seat/month | Yes - free and open source; no paid tier | Partial - free Hobby plan; Team plan is paid | Partial - free self-hosted; cloud plan has paid tiers |
| Open source | Yes - MIT license | No | Yes - MIT license | Partial - core open-source (Apache 2.0), product cloud-leaning | Yes - MIT license |
| Built-in MCP server | Yes - ships tiger-mcp; AI clients can list, read, and run requests without leaving the chat |
No | No | No | No |
| SOAP / WSDL import | Yes - import a .wsdl file; each binding operation becomes a POST with a ready-to-fill SOAP envelope (SOAP 1.1 and 1.2) |
Yes - WSDL import supported | No | No | No |
| OpenAPI & Postman import | Yes - OpenAPI 3 / Swagger 2 and Postman v2.0/2.1; also Insomnia v4, Bruno, curl | Yes | Partial - OpenAPI import available; Postman import via community tooling | Yes | Yes |
| Pre/post-request scripting | Yes - sandboxed JS with assertions; a tests panel shows pass/fail per assertion | Yes | Yes | Yes | Partial - pre-request scripts available; post-response scripting is limited |
| Collection runner | Yes - runs a folder sequentially with live pass/fail verdicts and a stop button | Partial - runner available; scheduled and automated runs require paid tiers | Partial - CLI runner available; GUI runner is limited | Partial - runner available on free tier with some limitations | Partial - basic runner available |
| Environments & secrets | Yes - named environments as plain files in environments/; secret values masked in the UI |
Yes | Yes | Yes | Yes |
| Native macOS / Windows / Linux | Yes - native Electron builds; Apple Silicon + Intel, Windows installer + winget, AppImage + .deb | Yes | Yes | Yes | Partial - primarily a web app; a desktop shell is available but less capable than a native client |
| No telemetry of your traffic | Yes - request URLs, headers, and bodies are never sent anywhere; optional anonymous usage analytics (method + status bucket only) with a single toggle to disable | No - requests pass through Postman's infrastructure for some features; review their privacy policy | Yes - no telemetry | Partial - desktop app sends requests directly; some sync features route through servers | Partial - self-hosted is fully private; hosted version may log request metadata |
Storage and Git workflow
The single biggest architectural difference between these tools is where your collections live. Postman and Hoppscotch (hosted) store collections server-side, which enables web access and sharing links but means your API definitions - including internal endpoint names and token shapes - sit on a third-party server. Insomnia stores data in a local SQLite database that is not easily diff-able and is difficult to include in a repository meaningfully.
Bruno and Tiger both store requests as plain text files, one per request, in a folder you own.
The difference is format: Bruno uses .bru files and Tiger uses .tiger
files. Both are human-readable and produce useful git diff output. Tiger additionally
ships a built-in Git panel so you can commit, branch, pull, and push without leaving the app.
Pricing in practice
Tiger and Bruno are entirely free with no seat limits and no paid tier. Postman's free plan caps the number of collaborators and automated collection runs. Insomnia's free Hobby plan covers individual use; team collaboration requires a paid plan. Hoppscotch's self-hosted Community Edition is free; the cloud and Enterprise editions carry per-seat pricing.
For a team of engineers who want to commit their API definitions alongside code and share them through a Git repository, both Tiger and Bruno avoid per-seat costs entirely. Tiger is the only one of the five that also ships an MCP server.
MCP server
Tiger is the only client in this comparison that ships a built-in MCP (Model Context Protocol)
server. The binary is called tiger-mcp. Once registered with an MCP-compatible AI
client such as Claude Desktop or Cursor, the assistant receives four tools:
list_requests, list_environments, get_request, and
run_request. The assistant can invoke any saved request directly from a chat
window. The collection remains on disk; no data is forwarded to any third party.
For teams that use AI assistants to debug or document APIs, this removes the copy-paste round trip between the API client and the chat window.
WSDL and SOAP
Legacy enterprise stacks often expose WSDL-described SOAP services that REST-first clients
treat as an afterthought. Tiger added first-class WSDL import in 0.4.0: point it at a
.wsdl file and it generates one POST request per binding operation, pre-filled
with a SOAP envelope body, the correct Content-Type header
(text/xml for SOAP 1.1, application/soap+xml for SOAP 1.2),
and the SOAPAction header for SOAP 1.1 services.
Among the five clients compared here, only Postman offers comparable WSDL import. Bruno and Insomnia have no WSDL importer; Hoppscotch has no WSDL importer either. You can still send raw XML bodies in all of them, but you must construct the envelope yourself.
What Tiger does not have (yet)
Fair comparison means listing gaps too. As of version 0.4.0:
- No web interface - Tiger is a desktop app only. Hoppscotch and the Postman web app both work in a browser without installing anything.
- No built-in team sync or shared workspace. Collaboration is entirely via Git (push to a shared repo, open a pull request). Postman and Insomnia offer managed sync that is easier for teams who do not want to self-host a Git remote.
- No marketplace of public APIs or collections. Postman's API Network has a large catalog of published collections. Tiger has no equivalent.
- No OAuth 2.0 authorization code or PKCE flows. Tiger supports the client credentials grant; interactive browser-based OAuth flows are not yet implemented.
- Builds are not yet code-signed on all platforms. On macOS, right-click the app and choose Open the first time. Windows builds install cleanly via winget.
If your team uses GitHub, GitLab, or Bitbucket for code review, Git-native storage means API changes can be part of the same pull request as the code that introduces them - reviewable, commentable, and rollback-able with the same workflow you already have.
Per-rival deep dives
Related pages
- What is Tiger? - overview of core concepts
- Importing collections - Postman, Bruno, Insomnia, OpenAPI, WSDL, and curl
- MCP server - connecting Tiger to Claude, Cursor, and other AI clients
- The .tiger format - how requests are stored as plain text