How to Migrate from Insomnia to .http Files

Insomnia is a good client that changed direction: since the Kong acquisition, the default experience leans on accounts and cloud sync, and many developers who chose Insomnia precisely to avoid that model are now looking for the exit. The good news is that plain REST requests — methods, URLs, headers, query parameters, JSON bodies — translate cleanly to .http files. Design documents, scripting, template-tag chains, and non-REST requests do not. A safe migration sorts your workspace into those two piles before deleting anything.

The destination is worth the trip: requests as plain text files that live beside your code, diff in Git, and run in any .http-aware tool — no export ceremony ever again.

1. Inventory the workspace

Work one collection at a time, not the whole app. For each, note:

requests people actually still run;
environment variables they reference (base URLs, tokens, tenant ids);
template tags and chained values (Response → Body Attribute and friends);
anything that isn't plain REST — GraphQL, gRPC, and WebSocket requests stay behind (Karve is REST-only; keep a tool that speaks those protocols for that work);
auth configuration per request or folder.

Mark the dead requests instead of migrating them. Most workspaces shrink pleasantly here.

2. Export — two routes that work

Route A: HAR export (best for bulk). Insomnia's export dialog can produce a HAR file alongside its own JSON format. HAR keeps the request definitions — method, URL, headers, body — which is exactly what a .http file needs. Save the export somewhere private first: it can contain live tokens in headers. (Format details and scope choices are in how to export an Insomnia collection.)

Route B: Copy as cURL (best for a handful). Right-click any request and copy it as a cURL command. This is the fastest path when you only care about five requests out of fifty.

3. Convert in the browser — nothing uploads

For a HAR export, open the free HAR → .http converter, drop the file in, and review the output. Two options matter for Insomnia exports: Trim browser-noise headers removes sec-*-style clutter (harmless to leave on), and Pretty-print JSON formats bodies for readable diffs. Each request becomes a ### block with the method, URL, headers, and body.

For copied cURL commands, paste each into the cURL → .http converter — it handles multi-line commands, -H, --data-raw, and -u Basic credentials.

Both tools run entirely in your browser; the export never leaves your machine. Review the conversion notes each tool prints — they list anything that couldn't be represented rather than inventing it.

4. Strip the tokens, rebuild the environments

Insomnia environments are JSON objects; .http environments are dotenv files. The mapping is mechanical — each key becomes a KEY=value line:

@baseUrl = {{host}}/api/v2

### List projects
GET {{baseUrl}}/projects
Authorization: Bearer {{token}}

Real values go in a git-ignored .env file; a committed .env.example documents the keys. The environments guide covers the full setup, and the auth guide shows the same pattern for every auth scheme. Replace any literal token the export captured before the file touches a repository.

5. Validate and organize

Run the converted files through the .http validator — it checks the syntax against a real parser and flags likely leftover secrets and undeclared variables. Then decide where files live: the sane default is next to the service they exercise, one file per API area, as argued in how to store API requests in Git.

Karve picks them up from there: virtual folders gather .http files from every repo without moving them, with per-file .env environments and persistent history. The Karve vs Insomnia comparison covers what you gain and lose in the switch honestly.

6. What doesn't move — and what to do about it

Template tags and response chaining have no .http equivalent in Karve. Where a chain fetched a token, keep the token request in the same file and paste its result into .env — manual, but visible and reviewable.
Scripting and tests need a new home (CI-side scripts or code-level tests).
GraphQL, gRPC, WebSocket requests stay in a protocol-capable tool.
Design documents (OpenAPI specs) aren't lost: convert the spec itself with the OpenAPI → .http converter.

Frequently asked

Does Karve import Insomnia workspaces directly? No. Karve opens .http/.rest files — the conversion above produces those files, and they stay yours whether or not you use Karve.

Is the migration reversible? Nothing about it deletes your Insomnia data. Run both side by side until the .http files have earned your trust — that's the honest way to migrate any tool.

What about my Postman collections? Same idea, different exporter — see how to migrate from Postman to .http files.

Weighing the alternatives first? See the Postman alternatives roundup and the head-to-head Karve vs Insomnia page.

How to migrate from Insomnia to .http files