Regression Node 24.0.0+: JSON.parse throws error on JSON containing U+2028 (line separator)/ U+2029 (paragraph separator)

[DAsfLeanIX]

Version

node v24.0.0+

What steps will reproduce the bug?

• Open a Node.js shell session (version 24.x or later).
• Run JSON.parse('{"text":"Hello
World"}') (The character between “Hello” and “World” is U+2028 (line separator). You can also use U+2029 (paragraph separator) instead.)

which will return with a Uncaught SyntaxError: Unexpected token ...

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

Summary

Note: V8's "Subsume JSON" documentation explicitly discusses making these code points processable in JavaScript string literals (https://v8.dev/features/subsume-json). Given that, this change is surprising and breaks existing production pipelines.

What do you see instead?

After upgrading to Node v24.x, JSON.parse() now throws a SyntaxError when parsing JSON text that contains literal U+2028 (line separator) or U+2029 (paragraph separator) inside a string value. The same input parsed successfully on Node v23.x. This looks like a regression or at least an undocumented behaviour change in Node/V8.

[targos]

This only happens in the REPL, so probably unrelated to JSON.

[targos]

@nodejs/repl smaller repro:

• Open the repl
• Paste "Hello
World"

[richardlau]

Likely to be caused by #57591 for #22448.

[DAsfLeanIX]

Just to clarify: this is not a “REPL-only” issue. This was just the easiest way to reproduce it.

Any JSON containing literal U+2028 or U+2029 will fail when parsed in real Node.js scripts or applications, not just when pasted into the REPL.

@richardlau thanks for the correlating PR. And yes the latest patch of 23 still supports this. 24.0.0 doesn't anymore

[targos]

Can you share a reproduction script that works outside of the REPL?
Sorry if I jumped to the wrong conclusion but I tried to paste your example in a JS file to run it and it doesn't error.

[DAsfLeanIX]

@targos we were able to hone in the issue at hand and especially with the PR provided by @richardlau we saw that it is indeed the behaviour change in readline coming in with v24 that broke our jsonl processing, splitting lines at unescaped line and paragraph separators. I guess that is by design then now? If not to recreate here is a small example

function parseJSONL(filePath) {
    return new Promise((resolve, reject) => {
        const fileStream = fs.createReadStream(filePath);
        const rl = readline.createInterface({
            input: fileStream,
            crlfDelay: Infinity
        });

        const results = [];

        rl.on('line', (line) => {
            if (line.trim()) {
                try {
                    const data = JSON.parse(line);
                    results.push(data);
                } catch (error) {
                    console.error('Error parsing line:', error.message);
                }
            }
        });

        rl.on('close', () => {
            resolve(results);
        });

        rl.on('error', reject);
    });
}

// Usage
parseJSONL('data.jsonl')
    .then(data => console.log(data))
    .catch(error => console.error(error));

Your test data can then look something like:

{"text": "This has a normal newline: foo\nbar"}
{"text": "This has U+2028 line separator: foo
bar"}
{"text": "This has U+2029 paragraph separator: foo
2029bar"}

[ricellis]

We ran into the same issue, I think the awkward thing for users here is that the round-trip like

• JSON.stringify()
• jsonlines file
• readline
• JSON.parse()

works fine for JSON values with \n and \r because they are escaped by JSON.stringify, but it doesn't work for \u2028 and \u2029 because they aren't.

It would be nice if this kind of round-trip could still work by giving readline an option to ignore \u2028 and \u2029 (e.g. if you know your jsonlines file is always using \n).

This is especially true considering the other angle to approach it is through JSON.stringify, but that doesn't seem to have any options to force escape any of the optionally escapable unicode characters , so to avoid double escaping with a replacer is some messy workaround like:

JSON.stringify(json, (_, value) => {
  if (typeof value === 'string') {
    return JSON.rawJSON(JSON.stringify(value)
      .replace(/\u2028/, '\\u2028')
      .replace(/\u2029/, '\\u2029')
    );
  }
  return value;
});

[Renegade334]

It would be nice if this kind of round-trip could still work by giving readline an option to ignore \u2028 and \u2029 (e.g. if you know your jsonlines file is always using \n).

or an IFS-esque option?

[vjvista]

Are you planning to add an option to conditionally revert to the old behavior (as some others have suggested)? If not, is there any recommended workaround for this? Upgrading to v24 is breaking some JSONL pipelines for us too.