Why does valid-looking JSON still break things sometimes?
Posted by davidbuilds2208@reddit | learnprogramming | View on Reddit | 19 comments
I ran into something recently that confused me a bit.
I had some JSON from an API response that looked totally fine at first glance, but it kept breaking things in my app.
Turned out there were small issues like missing quotes or a trailing comma — stuff that’s easy to overlook.
What confused me is that everything else seemed “normal” (no obvious errors until it actually failed somewhere downstream).
I feel like I keep running into this where JSON looks okay but isn’t actually valid.
How do you usually deal with this?
Do you just debug it manually every time, or is there a better way to catch/fix these issues early?
jcunews1@reddit
Having valid JSON syntax doesn't mean having valid JSON content.
szank@reddit
So you are saying that an invalid json still can look valid at a glance? yes it can. just like improperly indented python code or yaml or c++ that's missing a bloody semicolon somewhere.
Still invalid. Linting helps.
davidbuilds2208@reddit (OP)
Yeah exactly — that’s a good comparison.
I think what’s been annoying is not that it’s invalid, but that it’s often *almost* valid, so you don’t catch it until something breaks downstream.
szank@reddit
Id strongly suggest you stop thinking that "almost valid" is some kind of distinct category thats "better" than "invalid". Its like saying someone is "almost alive" which implies its different than just being dead.
r_hayess@reddit
Man, the trailing comma is the ultimate silent killer in JSON! We’ve all been there. JSON is very strict, so even one tiny character out of place makes the whole object unparseable. To stop debugging this manually, here is what pro devs use:
Linters & Formatters: If you use VS Code, install extensions like 'JSON Prettier' or 'ESLint'. They will highlight syntax errors in red before you even run the code.
JSON Validation Tools: Use online tools like JSONLint or browser extensions that format JSON responses. If it doesn't format correctly there, it’s not valid.
Schema Validation: For bigger projects, use something like JSON Schema. It doesn't just check if the JSON is 'valid', but also if it has the right structure (e.g., 'Does this user object actually have an email string?').
Try-Catch Blocks: Never assume an API response is valid. Always wrap your parsing logic in a try-catch block:
Stop looking with your eyes and let the tools do the work
davidbuilds2208@reddit (OP)
Yeah this is super helpful, especially for catching issues early.
I think where I keep getting stuck is after that step — once it’s flagged as invalid, I still end up manually fixing the same small stuff over and over again.
Feels like one of those things that should be trivial but somehow keeps eating time, especially when you’re just trying to move forward quickly.
Devatator_@reddit
Some parsers also have options to relax most things people can do to JSON, like trailing commas, comments, case sensitivity, etc.
r_hayess@reddit
Ah yes, forgot about that — JSON5 and JSONC do allow trailing commas which is a lifesaver honestly. Strict json is just unforgiving by design tho
Any-Range9932@reddit
Linting the answer. If the actual api endpoint is malformed, file a big with them and if you need to still use it, you can transform it to fit your use case
davidbuilds2208@reddit (OP)
Yeah that’s true if you can control the source.
I think where it gets tricky is when you *can’t* — like third-party APIs or quick internal stuff where you just need to keep moving.
BuiltByEcho@reddit
I'd stop treating it as an eyeballing/debugging problem and make JSON validation part of the boundary where data enters your app.
A practical setup:
One important distinction: if the API is returning trailing commas or missing quotes, that's not JSON with quirks — it's invalid JSON. Don't try to "clean it up" with regex unless you're forced to deal with a broken provider. Better to fail fast at the edge and surface a clear error.
davidbuilds2208@reddit (OP)
Yeah this makes sense for clean systems.
I think where I keep running into issues is more on the “messy boundary” side:
- third-party APIs I don’t control
- logs / exports
- quick internal tools
- sometimes AI-generated stuff
In those cases failing fast is technically correct, but in practice I still end up needing to *fix* the payload just to keep moving.
That’s the part that’s been surprisingly repetitive.
Astronaut6735@reddit
All code can look valid without being valid. It's why we get paid the big bucks.
Organic-Afternoon-50@reddit
Are you using an Agentic AI Coding assistant? If so, There's a few that constantly have this issue.. repeatedly breaking and fixing it.
davidbuilds2208@reddit (OP)
Not really, this was mostly with normal API responses.
But yeah I’ve seen similar issues with AI-generated JSON too — it often looks right but breaks in small ways.
Do you usually validate it after generation or just retry until it works?
AlwaysHopelesslyLost@reddit
It is not possible for invalid JSON to come out of a proper serializer. If you are seeing invalid JSON it is because somebody has royally fucked up and needs to fix their crap
13oundary@reddit
Why is JSON that's wrong wrong? I'm confused? What are you interacting with that produces wrong JSON that you expect not to?
0x14f@reddit
https://jsonlint.com
davidbuilds2208@reddit (OP)
Yeah I’ve tried jsonlint, it’s useful for spotting errors. I think what’s been tripping me up is having to manually fix things each time.