hurl Pretty-Print / Format JSON Response Bodies

Problem to solve

By default it seems that any JSON printed by hurl is not pretty-printed. Sometimes when I'm developing/debugging an API, I like to inspect the resulting JSON, which isn't doable in hurl without external tools.

This same feature request could also apply to HTML and XML, but at least for my use-case I am only asking for JSON. 😅

Proposal

Kind of similar to https://github.com/Orange-OpenSource/hurl/issues/1745, but I'd suggest either a CLI flag for this and/or a [Option] property to enable pretty printing for either an entire .hurl file or a single request.

Something like:

hurl test.hurl --pretty-print # or maybe something more descriptive and specific to JSON

and/or:

GET https://jsonplaceholder.typicode.com/users
[Option]
pretty-print: true # or maybe something more descriptive and specific to JSON

Additional context and resources

I currently pipe my hurl commands to jq to get the pretty-printed version of the JSON: https://github.com/jqlang/jq

However, this only works if I'm only printing a single response body; otherwise the printed output isn't valid JSON.

Jul 13 '23 03:07 Nezteb

Or an option to dump the responses into folders under a subpath. It would also help when writing tests and creating assertions.

[Option]
responses-path: ./out/runs
write-responses: true

Although using the curl output is very useful. :-)

May 25 '24 10:05 chrisguest75

Hi @chrisguest75, unless I've mistaken your point, you can do this with --output:

GET https://foo.com
[Options]
output: response.bin
HTTP 200

May 25 '24 10:05 jcamiel

Thanks, that does work for me @jcamiel. I had to update to 4.3.0 first though. Didn't realise I was using an older version.

May 25 '24 11:05 chrisguest75

Although it would be neat to have prettier JSON handling built in, I've been achieving something similar by piping output to jq.

Feb 02 '25 21:02 oatnog

I'm surprised and disappointed that this feature is still not supported. How do you guys even use hurl productively without this?

Mar 16 '25 11:03 1xX69

@Nezteb the issue is not open to contribution, but still open, we'll do it.

Jun 21 '25 01:06 jcamiel

@lepapareil @fabricereix quick questions about the feature, I would like your opinions:

I'm thinking about two more options: --pretty and --no-pretty. By default, and in interactive session, we'll prettify JSON ouput (--pretty is default):
- If you do not want pretty output, you'll have to use --no-pretty
- if you want pretty output while redirecting, you'll have to explicitely force pretty print with --pretty
What about errors? Whether --pretty is implicit or set by user, what do we do if we have an error (JSON is not valid etc..)? I don't know how httpie is managing it for instance, I think we should silent fail if we have any error.
When do we try to pretty print? Do we try do pretty print every response (whether or not the Content-Type response is JSON), or only if we detect JSON content type in the response headers? My opionion:
- if Content-Type is present and of type JSON, try pretty print
- if Content-Type is present and not of type JSON, do nothing (unless explicit --pretty)
- if Content-Type is not present, try pretty print as best effort (silent failing if not valid JSON)
--pretty take --color/ --no-color into account

Aug 19 '25 07:08 jcamiel

Yes it makes sense to have a consistent behavior between color and pretty (implicit w/o option and explicit with the options).

Relating to an invalid JSON, we can indeed leave the response as received without producing any errors. That's also the behavior of httpie.

For the implicit mode, I think I would prefer to activate the pretty formatting only with the content-type header. If the response is a valid JSON, but with the wrong content-type header, I would leave the response as received. But this is not the behavior of httpie.

    $ curl localhost:8000/sample.txt
    {"name":"Bob"}
    
    $ n/http GET localhost:8000/sample.txt
    HTTP/1.0 200 OK
    Content-Length: 15
    Content-type: text/plain
    Date: Thu, 21 Aug 2025 10:34:07 GMT
    Last-Modified: Thu, 21 Aug 2025 10:33:39 GMT
    Server: SimpleHTTP/0.6 Python/3.13.1
    
    {
        "name": "Bob"
    }

Aug 21 '25 10:08 fabricereix

With "implicit" prettify, we prettify the body if the content is JSON and do nothing otherwise. We'll have a small penalty for trying to parse JSON in anycase. Maybe we can try prettify if Content-Type is explicitely JSON and text like?

Or maybe simpler:

without --pretty, pretiffy only JSON-like content type
with --pretty, try to pretify no matter what the content type is

Aug 21 '25 12:08 jcamiel

@jcamiel @fabricereix, not sure yet on the best solution, we should map out all real use cases including interactive/non-interactive mode and future features like websocket to clarify the default option and how smart it should be. Better to discuss this together live 🧐.

Aug 26 '25 15:08 lepapareil

@fabricereix @lepapareil Now that we have an "easy" way of pretty printing JSON, I see two places where we could also use it(or not):

--error-format: with --error-format long we output the HTTP response whenever there are asserts failure
--very-verbose: in this mode, we also log the HTTP response.

In details: