Here is one small request. It posts a name to an API:
curl -X POST https://api.example.com/users \
-H "Content-Type: application/json" \
-d '{"name":"Ada"}'Paste that into Postman, Insomnia or the JetBrains HTTP Client and you get the same request back. It works so smoothly that nobody stops to ask what actually got passed along. I did, while writing the import code for Plunger, a small open-source API tool we make. This is what I found out about how requests get written down.
There is no spec to argue about. Every API doc has a curl example, and browser dev tools can copy a request as one. Postman, Insomnia and the JetBrains HTTP Client all take it.
Reading one is harder than it looks. It's shell syntax, so before you can look at a single flag you have to split the text the way a shell would, quotes and all. Then there are flags that swallow the next word without mattering, like -o out.json or -m 30. Skip the flag but forget its value and the value gets mistaken for the URL. And -F means multipart: name=value is a text field, name=@path is a file.
One choice in Plunger is deliberate. -d @body.json is not read from disk. The body just becomes the text @body.json, so importing a command can never quietly read a file off your machine. (If you want the flags themselves explained, we wrote a guide to converting a curl command to code.)
Save the network tab as a HAR file and you get JSON with one entry for every request the page made. Our request looks like this in there:
{"log": {"entries": [{"request": {
"method": "POST",
"url": "https://api.example.com/users",
"headers": [{"name": "Content-Type", "value": "application/json"}],
"postData": {"mimeType": "application/json", "text": "{\"name\":\"Ada\"}"}
}}]}}Two things worth knowing. First, HAR is a standard in practice only. The spec everyone points to describes version 1.2, and the copy the W3C hosts is stamped "DO NOT USE": it says the working group never published it and it has been abandoned. Everyone uses it anyway. Second, it is full of secrets. Cookies, tokens and request bodies are all in there, and the spec itself warns that a HAR "may contain privacy & security sensitive data". Treat one like a password before you attach it to a bug report.
A HAR holds every request the page made, so a good importer shows you the list and lets you pick. That is what Plunger does. It also skips the HTTP/2 pseudo-headers like :authority, which browsers record but which can't be sent. Postman has imported HAR files since version 9.6 in January 2022, and Insomnia can both import and export them.
The part I found most interesting is that Bruno, Postman and Insomnia each recently added a format that is just text you can commit to Git.
Bruno started there. Its .bru format is one text file per request, with collections as ordinary folders. In January 2026 it added OpenCollection, an open YAML specification with a published JSON Schema, and since version 3.1 in February, new collections are YAML by default. The reasons Bruno gives are pleasantly boring: editors and linters understand YAML, CI understands YAML, and they say it parses four to five times faster than .bru. Both formats stay supported, and they call the move between them lossless.
Postman's classic collection is one JSON file (version 2.1, with a published schema). Its current docs describe Collection v3, which is YAML spread across files: every request is a .request.yaml file with a folder beside it for its examples and scripts. The stated aim is that "humans, AI agents, and automation tools can read, diff, review, and safely change collections in the same way as source code". It goes with Postman v12 becoming Git-native. One catch: running v3 collections needs the Postman CLI instead of Newman.
Insomnia is on YAML too. It exports its v5 YAML format and still imports the old v4 JSON, along with Postman collections, HAR, OpenAPI, Swagger, WSDL and curl.
I couldn't find real usage numbers for any of this, so I won't tell you who is winning. What I can say is that all three landed in the same place: readable files, small diffs, something you can review in a pull request.
Two more formats drop the collection idea altogether.
Hurl is a command-line tool, open source under Apache-2.0, written in Rust and built on libcurl. A request and its check are just text:
GET https://example.org/api/health
HTTP 200And .http files put the same idea inside your editor. JetBrains IDEs read them, and can turn a pasted curl command into one and back again. Visual Studio 2022 (17.8 and later) reads the same format, which Microsoft says was inspired by the VS Code REST Client extension. Ours would be:
POST https://api.example.com/users
Content-Type: application/json
{"name":"Ada"}An OpenAPI file doesn't describe a request. It describes the whole API: its paths, parameters and responses. Tools import it to generate requests, so it sits next to these formats and not among them. The current version is 3.2.0, released in September 2025. If you're curious how it relates to a Postman collection, we have a Postman to Swagger converter and an article on why OpenAPI is worth using.
If you have one request from a doc, use curl. It is the most portable and you can read it before you run it. If you need to reproduce what a browser really sent, save a HAR, then delete everything you don't need before you share it.
Moving a whole collection between tools? Use the importer of the tool you are moving to, then check the scripts and auth settings by hand. And if you want your requests in the same repo as your code, pick one of the plain-text options so a diff shows what changed.
We built Plunger for the first two cases: paste a curl command or open a HAR, send it, read the JSON. It deliberately doesn't keep collections. It's free and open source, at metamug.com/util/plunger and github.com/metamug/plunger. And if all you want is a curl command turned into code, the cURL to Code converter does that.