Tiger vs Postman

Both Tiger and Postman let you build, send and organize HTTP requests. The difference is where your collections live, what it costs to collaborate, and whether any of your request data ever leaves your machine.

The core difference

Tiger stores every request as a plain-text .tiger file in a folder on your machine. That folder is a normal Git repository. You commit collections, open pull requests against them, and resolve merge conflicts in your regular editor. There is no cloud backend, no sync service, and no sign-in. Requests, tokens and responses never leave your computer.

Postman's model is the inverse: collections live in Postman's cloud by default. Collaboration happens through Postman's workspace UI. Local or offline-only storage is a paid-plan feature. The result is a mature platform with a large public API network and browser-based workspaces - but one that requires an account, connectivity for many features, and a paid plan once a team is involved.

Feature comparison

The .tiger file format

A Tiger collection is a folder of plain-text .tiger files - one per request - that you commit alongside your code. The format is human-readable and diff-friendly. Here is a complete example:

meta {
  name: Create post
  seq: 2
}

post {
  url: {{baseUrl}}/posts
}

headers {
  Content-Type: application/json
  ~X-Debug: 1
}

body:json {
  { "title": "Hello from Tiger" }
}

auth:bearer {
  token: {{token}}
}

capture {
  postId: body.id
}

A ~ prefix disables a header or parameter without deleting it - so you can toggle it off and back on in the UI and Git sees a one-character diff. The capture block writes a response value (status code, a header, or a JSON body path) into an environment variable for the next request in a chain.

Environments live in an environments/ subfolder as their own .tiger files. Secret values are masked in the UI but still stored locally on disk.

MCP server

Tiger ships a built-in MCP server (tiger-mcp) that gives AI clients - Claude, Cursor, or any MCP-compatible assistant - structured access to your collection. The server exposes four tools: list_requests, list_environments, get_request, and run_request. Every response includes the status code, timing, response headers, and a pretty-printed body. Your collection stays on disk; nothing is sent to any third party.

To register Tiger with Claude Desktop, add the following to claude_desktop_config.json:

{
  "mcpServers": {
    "tiger": {
      "command": "node",
      "args": ["/path/to/tiger/out/mcp/server.mjs", "/path/to/your/collection"]
    }
  }
}

Postman has no equivalent. This makes Tiger the only API client with an MCP server built in from the ground up.

WSDL / SOAP import (new in 0.4.0)

Tiger 0.4.0 added a WSDL importer. Drop in a .wsdl or .xml file and Tiger parses every binding operation into a ready-to-send POST request: the body is pre-populated with a SOAP envelope you fill in, the Content-Type is set to text/xml (SOAP 1.1) or application/soap+xml (SOAP 1.2), and the SOAPAction header is added for SOAP 1.1. Postman also supports SOAP, so this brings Tiger to parity for legacy SOAP/WS-* APIs.

When Postman is still the better choice

Tiger is the right tool for teams that want their API definitions in version control, no accounts, and no ongoing cost. Postman leads in three specific areas:

• Public API network. Postman hosts tens of thousands of ready-made collections for popular APIs. If your workflow starts by importing a vendor-published collection, Postman's network is far larger than anything Tiger currently provides.
• Browser-based workspaces. Postman's web interface lets stakeholders outside engineering view and run collections in a browser without installing anything. Tiger requires the desktop app, which makes it less suited to product managers or QA teams who prefer a web UI.
• Hosted, scheduled monitoring. Postman's cloud monitors run your collections on a schedule and send alerts without any server you maintain. Tiger's performance runs are manual and local, so continuous monitoring requires your own CI pipeline or an external uptime tool.

Migrating from Postman

Tiger can import any Postman v2.0 or v2.1 export - collections, environments, auth settings and folder structure all carry over. The import takes a few seconds; most teams are sending requests within a minute of opening Tiger for the first time.

1. In Postman, export your collection as Collection v2.1 (a .json file).
2. In Tiger, click Import in the sidebar (or drag the file onto the window).
3. Tiger creates a folder on disk with one .tiger file per request. Add it to Git and push.

Environments export separately from Postman. Export each environment as JSON, then import it in Tiger the same way. Captured secrets remain in your local environments/ folder and never leave your machine.

Common questions

Can multiple teammates use Tiger without paying anything?

Yes. Tiger is free and open source under the MIT license. Any number of engineers can clone the same Git repository and open it as a Tiger collection. There are no seats, no workspaces to invite people into, and no plan upgrade required.

Does Tiger work completely offline?

Yes. Tiger has no cloud backend. All features - collections, environments, request history, the collection runner, performance runs, and the built-in Git operations - are available with no network connection at all. The only network activity Tiger initiates is the HTTP requests you explicitly send, and an anonymous usage ping that can be turned off in Settings under Privacy.

What happens to pull request reviews when API definitions change?

Because each request is a .tiger file, changing a URL, adding a header, or updating a body appears as a normal line-level diff in your pull request. Reviewers can comment on the exact line that changed. Merge conflicts are resolved with the same tools you use for code. Postman's change history is internal to its platform and not visible in your code review workflow.

Is Tiger production-ready?

Tiger 0.4.0 is a public release with a growing user base. The core format, importers, scripting engine, and MCP server are stable. macOS builds are signed and notarized; Windows builds are available via winget (winget install TaoufikJabbari.Tiger); Linux ships as AppImage with auto-update and as a .deb for Debian/Ubuntu. The project is open source and accepts contributions.

Related pages