## TL;DR
Nuclei writes one JSON object per line. The error means the final line got cut mid-write, usually because the process was killed or the downstream pipe closed early. Drop the incomplete trailing line (or the partial middle line) and everything else parses. Rerun with output written straight to a file if the run itself was interrupted.

```text
unexpected end of JSON input
```

## Use this when
- A parser fails on `unexpected end of JSON input` reading nuclei `-jsonl` output.
- The failure points at the last line, or at one line in the middle of the file.
- Results were piped through `jq`, a Python script, or another consumer.

## Not for this skill when
- Nuclei produced zero findings. That is a template or targeting problem, not corruption.
- The output file is missing entirely. Check the `-o` path and disk space instead.
- The JSONL was hand-edited. Re-derive it from a fresh run.

## Steps
1. Inspect the tail: `tail -c 300 results.jsonl`. Verify: the file ends mid-object with no closing brace, confirming a truncated final line.
2. Find every unparsable line with a short loop: read the file, try `json.loads` on each line, print the failing line numbers. Verify: only the trailing line (or one line) fails.
3. Drop the bad line: keep only the lines that parse, writing the result to `clean.jsonl`. Verify: the full clean file parses line by line.
4. If the run was interrupted, rerun writing straight to disk: `nuclei -u YOUR_TARGET_HOST -t /path/to/templates -jsonl -o results.jsonl`. Verify: the new file ends with a complete line.
5. If piping is required, make the consumer tolerate a partial tail or flush the pipe fully before parsing. Verify: a rerun through the same pipe produces no trailing garbage.

## Variant phrasings
### nuclei jsonl truncated last line
Same failure, phrased as the symptom.
### unexpected end of JSON input nuclei pipe
The piping-specific search.
### nuclei jsonl corrupt when piping results
How testers describe it in reports.

Compatibility: nuclei v2/v3 `-jsonl` output. Pipes through jq, Python json, or log shippers all show the same single bad line.

## Why it happens
JSONL has no end-of-stream marker; each line is independent. When nuclei is SIGKILLed, the disk fills, or the pipe consumer exits early, the last buffered write never lands, leaving a half-written object. The parser is correct to complain: the bytes really are incomplete.

## Edge cases / pitfalls
- A truncated line in the MIDDLE of the file points at a full disk or a crashed writer, not a pipe problem. Fix the environment, do not just filter.
- Never hand-close the brace yourself. You will invent severity and template fields that were never emitted.
- `-silent` changes console noise, not JSONL framing. It does not fix this.
- If every line fails to parse, the file is not JSONL at all. Check whether `-json` was used instead of `-jsonl`.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Py19tqQ2R1eRXXvmflHhjQ