Most API teams eventually end up with the same awkward split. One request gets debugged in curl, another lives in a GUI collection, login state is re-created in ad hoc scripts, and the thing that finally lands in CI is often a fourth version written in a test framework. Hurl is interesting because it tries to collapse those layers into one artifact. Its official definition is simple: a command-line tool that runs HTTP requests defined in a plain-text format, can chain requests, capture values, and evaluate queries on headers and response bodies across HTML, REST, SOAP, GraphQL, and other XML/JSON APIs.[1]

That sounds modest until you read the current surface area more closely. As of 2026-05-03T02:40:00Z UTC, the GitHub API reports 18,865 stars, 721 forks, 197 open issues, and a most recent push timestamp of 2026-05-02T20:15:06Z for Orange-OpenSource/hurl.[5] The latest tagged release is 8.0.1, published on 2026-04-29, and the immediately preceding 8.0.0 release added raw multiline strings, a new RFC 9535 JSONPath module, and additional certificate-query support.[6][7] That does not prove strategic fit on its own, but it does show an actively maintained tool whose format and boundaries are worth understanding before dismissing it as "just another HTTP client."

Thoughtworks' April 2025 Technology Radar captured the project cleanly: Hurl is a "Swiss Army knife" for sequences of HTTP requests, useful both for automation and automated API testing, with the extra advantage that the tests can sit in the repository as text.[8] That is the right frame. Hurl matters less as a prettier curl wrapper than as a way to make HTTP behavior reviewable in the same place as the code that depends on it.

Image context: the cover deliberately avoids a UI screenshot and keeps the article in the physical world of repo-native testing: a developer's desk, terminal-driven work, and notes beside the code. That immersive setting fits the article because Hurl's value appears when HTTP sessions become files a developer can read, diff, run, and review in the same workflow as the service itself.[1]

The file itself is the contract

The core design move is to treat one text file as both request script and response expectation. Hurl's homepage describes a format that can run requests, chain them together, capture values, and test the received output.[1] That means the useful unit is not "a request tab" or "a saved collection entry." The useful unit is a .hurl file that can travel with a service, a gateway, a test fixture, or an operations runbook.

That repo-native shape changes the economics of review. A teammate can inspect a login flow, a health-check sequence, or a regression case as text instead of opening a separate GUI export. Thoughtworks makes the same point from the outside when it says Hurl tests can be stored in the code repository and that this simplicity is part of the appeal.[8] In practice, that makes Hurl most persuasive for teams that want HTTP behavior to be diffable and code-reviewed, not merely executable.

The reason this matters in 2026 is that many API surfaces are now broader than a single JSON call. They include redirects, auth headers, cookie state, HTML handshakes, and mixed internal/external gateways. Hurl's format is narrow enough to stay readable but wide enough to keep those steps in one file.[1] That is a much better fit than scattering the same flow across shell history, browser tabs, and framework-specific helpers.

Captures keep multi-step sessions legible

Hurl becomes more than a text version of curl once captures enter the picture. The official captures tutorial shows the tool extracting a CSRF token from an HTML login page with XPath, storing it in a variable, and then reusing that value in a subsequent POST request.[2] The same tutorial explains the larger rule: captures and asserts share query language, so values can be pulled from HTML, JSON, cookies, and other response surfaces with the same general mental model.[2]

That is the feature that makes Hurl useful for real session tests rather than single-call demos. A login sequence, a redirect chain, or a two-step API workflow stays linear. You read the first request, see what was captured, then read the second request that consumes it. The captures tutorial also notes that Hurl does not follow redirects by default, so each step can be run and checked explicitly.[2] That choice is revealing. Hurl is not trying to hide protocol behavior behind convenience magic. It wants the HTTP conversation to remain visible.

For operators and application teams, that visibility is often the whole point. If a gateway starts issuing the wrong Location header, or an HTML form stops exposing the token field your automation expects, a plain-text test should fail at the exact boundary where the protocol changed. Hurl's capture model makes that kind of failure easy to localize.[2]

Assertions and reports are what make it CI-worthy

The second big design move is that Hurl treats response checking as first-class syntax, not as comments around a request. The asserting-response docs list checks on status, headers, body content, bytes, XPath, JSONPath, regex matches, URL, redirects, IP address, duration, variables, and SSL certificate values.[3] That breadth matters because it lets one file stay close to the protocol surface. You can check the HTTP result, the payload structure, and some transport-level details without immediately escaping into a programming language.[3]

The testing surface completes the picture. The running-tests docs describe --test mode for test-oriented output, plus HTML and JSON reports, and the manual documents JUnit reporting as well.[4] The same testing docs note that the HTML report includes the input Hurl files in rendered form and that JSON reports preserve structured run results for later processing.[4] Put differently, Hurl does not stop at "the request can be run." It pushes all the way to "the request file can act as a CI artifact."

This is where the project becomes especially practical for small and medium integration suites. A team can keep request files near the service code, inject environment variables through the supported HURL_VARIABLE_... mechanism, run them under --test, and publish HTML or machine-readable reports in the pipeline.[4] That is a cleaner operational story than maintaining one set of exploratory API client tabs and another set of pipeline-only tests.

The boundary is that Hurl is deliberately narrow

Hurl is strongest when the HTTP exchange itself is the thing you need to preserve. It is ideal for login sequences, smoke tests, gateway checks, contract-like response assertions, and regression cases where protocol details matter more than application-side control flow.[1][2][3][4] Read together, the docs and the Thoughtworks note point toward the same conclusion: Hurl wins by keeping the artifact small, textual, and reviewable.[1][8]

That same design also defines the limit. Hurl is not trying to become a full programming harness, a sprawling collaborative GUI workspace, or a replacement for every property-based or load-testing tool a platform team might use. Its value comes from refusing that sprawl. If your problem requires heavy branching logic, large-scale synthetic data generation, or deep custom orchestration, you will eventually want a general-purpose language or a different class of test system. But if the thing you need to pin down is an HTTP session with precise checks, Hurl's narrowness is an advantage, not a defect.

That is why Hurl is worth a project introduction in 2026. The live idea is not that plain text is romantic. The live idea is that HTTP behavior becomes easier to own when request sequence, captured state, assertions, and reports all live in one versioned artifact.[1][2][3][4][8] Hurl's current release cadence and upstream activity suggest that this design has moved well beyond novelty status.[5][6][7]

Sources

1. Hurl home page - project overview, plain-text request format, chained requests, captures, assertions, and protocol scope across HTML, REST, SOAP, GraphQL, and other XML/JSON APIs.
2. Hurl Docs, "Captures" - multi-request chaining, CSRF-token capture with XPath, variable reuse, and explicit redirect handling.
3. Hurl Docs, "Asserting Response" - supported assertion types including headers, XPath, JSONPath, regex, redirects, duration, and SSL certificate checks.
4. Hurl Docs, "Running Tests" and manual reporting options - --test, HTML and JSON reports, rendered input files in reports, and environment-variable injection via HURL_VARIABLE_....
5. GitHub API snapshot for Orange-OpenSource/hurl - stars, forks, open issues, default branch, and recent push/update timestamps at article creation time.
6. GitHub release page for Hurl 8.0.1 - latest tagged release and publication date.
7. GitHub release page for Hurl 8.0.0 - release note baseline for raw multiline strings, RFC 9535 JSONPath support, and related 8.x changes.
8. Thoughtworks Technology Radar, "Hurl" - external assessment of Hurl as a plain-text request-sequencing and automated API testing tool whose tests can live in the code repository.