Clean JSON Output (Structured Findings)

[subfinder-enum]

Feature Request: Clean JSON Output (Structured Findings)

Description:

I would like to request support for a clean, structured JSON output format that only includes meaningful fields like url, status_code, fqdn, and ip, without raw HTTP data or response bodies. Currently, the -jsonl (-j) output includes verbose content such as request headers, raw bodies, and metadata, which makes post-processing or automation difficult.

Suggested implementation:

• Add a flag like --structured-json or --minimal-json
• Allow selection of specific fields using something like:

  katana -u https://example.com -structured-json -fields url,ip,status_code,fqdn -o results.json

• Output should look like this:

  [
    {
      "url": "https://example.com/page1",
      "ip": "192.0.2.1",
      "status_code": 200,
      "fqdn": "example.com"
    },
    {
      "url": "http://test.local/page2",
      "ip": "192.168.1.100",
      "status_code": 404,
      "fqdn": "test.local"
    }
  ]

This would be much cleaner and easier to use in downstream tools and scripts.

---

Even when using -or (omit raw) and -ob (omit body), the JSONL output is still overly verbose and lacks a simplified structure with flat fields like url, status_code, and ip. A dedicated flag for structured, concise output would better support automation and analysis workflows.

---

Description of the use case of this feature:

In automation pipelines, it’s common to consume Katana output in other tools (e.g., jq, Python, bash, SIEMs). The current JSONL output is verbose and includes unnecessary data (raw requests, full responses, body content, etc.).

A minimal, structured JSON output would:

• Make scripting and parsing easier
• Eliminate the need for custom JSON post-processing
• Enable better integration with monitoring, alerting, and reporting tools
• Provide only the essential fields for analysis (e.g., url, IP, HTTP status)

This would align Katana better with use cases for automation, continuous scanning, and reporting.

[hanXen]

Hi @subfinder-enum,

I completely agree that a clean, structured JSON output with selectable fields would be useful for post-processing and automation workflows. I'd like to ask for some clarification.

(Note: I'm not a maintainer — just sharing questions after exploring the code.)

You suggested the example command:

katana -u https://example.com -structured-json -fields url,ip,status_code,fqdn -o results.json

However, it appears that neither ip nor fqdn are included in the default -json output (please let me know if I’m mistaken and what the current output shows).

As for fqdn, it's handled in fields.go and can be emitted via the -output-template (-ot) flag, but it isn’t part of the default -json output.
For the ip field in your example, could you clarify how you'd expect it to be populated?

Clarifying this will help determine whether the goal is to produce a minimal version of the current JSON output, or to extend the output to include additional fields not currently available in the -json mode. Thanks!

[dogancanbakir]

@subfinder-enum Are you looking something like we implemented in naabu or ? projectdiscovery/naabu#1387

[hanXen]

Hi @dogancanbakir,

Hope you're doing well.

I saw this issue has been assigned. Just to let you know, I’ve been looking into it and have a fix ready.

The ideal fix uses the new FilterStructToMap utility, which was recently merged in projectdiscovery/utils#674. This same approach was also applied to resolve the issue in projectdiscovery/naabu#1546.

I attempted to apply it to katana, but its dependencies seem to be out of date with the latest utils library, which leads to several build errors (e.g., with errorutil, httputil.CookieJar, etc.).

If you’re planning to update katana's dependencies soon, I’d be happy to open a PR with the -eof feature implemented right after.

Please let me know if I can help in any way. Thanks!

[dogancanbakir]

@hanXen It would be awesome! Why don't you raise a PR and we fix the errors and merge them all at once?

[hanXen]

@dogancanbakir That's great, thanks for the green light! I'll open a draft PR shortly with the feature logic.
As expected, it will fail the CI checks due to the dependency issues, but like you said, we can use it as a starting point to fix them together.