Skip to content

Compatibility Overview

The .http format has achieved remarkable organic adoption — at least 16 actively maintained tools parse and execute these files — yet it lacks a formal standard. Three layers of compatibility have emerged.

Universal Supported identically by all major implementations.

Universal core — request syntax, ### separators, # and // comments, {{variables}}, @var = value definitions. Works identically everywhere.

Widely Supported Supported by 3+ implementations, possibly with syntax variations.

Widely supported — environments (http-client.env.json), file includes (< filepath), metadata tags (@name, @no-redirect, @no-cookie-jar), auth helpers (Basic, Digest), dynamic variables ($uuid, $timestamp, $randomInt), multipart form data. Shared by most tools with minor syntax variations.

Implementation-Specific Unique to a single implementation. Not portable.

Implementation-specific — scripting, assertions (??), protocol extensions (WebSocket, gRPC, MQTT, AMQP), import/run, Crypto API, Faker random data, Azure Key Vault secrets. Not portable without targeting a specific client.

Explore feature-by-feature compatibility in each area:

To stay inside the portable subset when writing files, see Writing Portable Files.

This compatibility reference is maintained collaboratively. The data lives in structured YAML files that anyone can update via pull request. It is also the evidence base for the standardization process: features enter the versioned core profile when the implementations already agree.

This is not a ranking. Every implementation makes different tradeoffs — broad IDE integration, maximum features, cross-client compatibility, or simplicity. The goal is to help you understand what your client supports and write portable .http files when that matters.