isahc: a Rust HTTP client that puts libcurl behind a futures API

libcurl does the protocol work, the crate does the ergonomics

Isahc stands for Incredible Streaming Asynchronous HTTP Client and is an asynchronous HTTP client for Rust that uses libcurl as an HTTP engine inside, providing an API on top that integrates with Rust idioms. The README is explicit about the division of labour. Isahc uses libcurl under the hood to handle the HTTP protocol and networking, and safe Rust bindings to libcurl are provided by the curl crate, which you can use yourself if you want to go directly to curl. The value Isahc delivers is on top of vanilla curl: a simpler, more idiomatic API, and the hard work of turning the powerful curl multi interface into a futures-based API. The four reasons given for choosing curl as the engine are that it is stable, actively developed and very popular, that it is well supported on a diverse list of platforms, that HTTP has many unexpected gotchas across different servers and curl has been around long enough to handle them, and that it is well optimized and able to implement asynchronous requests.

Synchronous and async over the same core

The key feature list is short and the top entry is the API shape. Isahc offers an ergonomic synchronous API as well as a runtime-agnostic asynchronous API with support for async/await, and the core is fully asynchronous, with incremental reading and writing of request and response bodies and connection multiplexing. Runtime-agnostic is the important word: the async API does not tie you to a specific executor, which matters when the surrounding application already has its own. Requests and responses use the http crate as the interface, so a request builder takes http types rather than curl types, and the response you read is an http type too. Other entries in the list cover configurable request timeouts, redirect policies and Unix sockets, sessions and cookie persistence, and automatic request cancellation on drop, which is the behaviour you want when a future is dropped mid-flight.

The whole client in eleven lines

The README's example is a complete program that prints the response body from a URL, and it is the fastest way to see the shape:

use isahc::prelude::*;

fn main() -> Result<(), isahc::Error> {
    // Send a GET request and wait for the response headers.
    // Must be `mut` so we can read the response body.
    let mut response = isahc::get("https://example.org")?;

    // Print some basic info about the response to standard output.
    println!("Status: {}", response.status());
    println!("Headers: {:#?}", response.headers());

    // Read the response body as text into a string and print it.
    print!("{}", response.text()?);

    Ok(())
}

The detail that trips people up is in the comment on the third line: the response binding has to be mut so the body can be read. The prelude import brings in the request helpers, and the fallible calls use the question mark operator with isahc::Error as the error type.

Feature flags decide what you compile in

The Cargo manifest shows the shape of the crate, and the default feature set is default-tls, http2, log, static-curl and text-decoding. The TLS choices are the interesting part because there are several. default-tls means rustls-tls, which is static-curl plus the tls feature plus rustls on both the curl and curl-sys sides, and there is a rustls-tls-webpki-roots variant that swaps the platform trust store for the webpki root certificates through the trust-webpki-roots feature. native-tls goes the other way and pulls in the tls feature plus curl's and curl-sys' ssl features, with a native-tls-static variant for static OpenSSL. If you need the Kerberos support that the README links to, the spnego feature turns on curl-sys's spnego support. Everything else is opt-in: cookies brings in httpdate, json brings in serde and serde_json, log bridges tracing to the log crate, psl adds the public suffix list for cookie handling, and unstable-interceptors is an empty marker feature for an experimental API.

Adding it is one line in Cargo.toml

Installation is a Cargo dependency, and the README gives the version explicitly:

[dependencies]
isahc = "2.0"

The minimum supported Rust version is stable Rust 1.85 or greater, and the project only guarantees that Isahc will compile with a rustc version of at least 1.85, though it might compile with older versions and that could change at any time. The version is explicitly tested in CI and may only be bumped in new minor versions, and any change is called out in the release notes. The manifest agrees, with rust-version set to 1.85 and the edition at 2024. The crate is on crates.io as isahc, the documentation is on docs.rs, and the repository carries a rust-toolchain.toml, a mise.toml, an INTERNALS.md, an AI_POLICY.md and a deny.toml for dependency licence checks.

Two situations where the README tells you not to use it

The section on when not to use Isahc is unusually direct, and both cases are worth reading before you commit. The first is tiny binaries: if creating an application where tiny binary size is a key priority, Isahc may be too large, because while the dependencies are carefully curated and a number of features can be disabled, the core feature set includes things like async which does have some file size overhead, and the README points at ureq as something more suitable. The second is WebAssembly: if your project needs to be compiled to WebAssembly, Isahc will probably not work, which follows from the design decision to make libcurl the engine. The stated project goals are an ergonomic and innovative API easy for beginners and flexible for advanced uses, a high-level wrapper around libcurl, a lightweight dependency tree and small binary footprint, and optionally compiled extra client features. The non-goals are equally clear: support for protocols other than HTTP, and alternative engines besides libcurl, since other projects are better suited to that.

The curl crate is the escape hatch, and 2.0 is a recent line

If Isahc does not expose what you need, the README points you at the curl crate directly, the safe Rust bindings to libcurl that Isahc itself uses. That is a real design statement about where the boundary sits: Isahc is a convenience layer, and it is not trying to hide the engine. If you need a protocol libcurl supports but Isahc does not expose, you drop down a level rather than waiting for the wrapper to grow. On the release side, the crate is on 2.0.1, published on 2026-07-05, with 1.8.3 the same day and 2.0.0 on 2026-05-25, so the 2.x line is recent and the project moved from 1.x to 2.0 in a matter of weeks. The maintenance badge in the manifest says passively-maintained, the repository is not archived and the last push was on 2026-10-19, so the crate is still receiving work. The licence is MIT for the source and documentation, with the Isahc logo and related assets under Creative Commons Attribution 4.0.

Editorial conclusion

Adopt isahc if you are writing Rust and want HTTP and HTTPS with libcurl's battle-tested protocol handling behind a futures-based API, especially if you need HTTP/2, cookie sessions or Unix sockets. Do not adopt it for a tiny binary, since the core feature set includes async with real file size overhead, and do not adopt it at all for a WebAssembly target. Before you commit, pick your TLS backend among the rustls and native-tls options in the feature list, and read INTERNALS.md in the repository, which is where the design decisions behind the wrapper are written down.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sagebind/isahc on GitHub