Like JS from which it sprang, it lacks an integer type. Fortunately, parsers written for languages that do have integers can usually parse them correctly.

(If you don't know why this might matter, try opening your browser's Javascript console and evaluating 10000000000000001)

That's my peeve, though. I suspect that Tom is probably more concerned with readability. TOML also looks like it can be parsed a line at a time and doesn't really need to do any recursive parsing, so you could probably parse a stream of it as it arrives, which I imagine is trickier with JSON.

IMHO, although it's very easily readable by humans, it's not quite as easily written by humans.

I've always preferred INI over JSON for this reason.

I use it liberally, but the only thing that I find wrong with json is the [\u2028\u2029] issue:

{"The invisible character":"really messes with javascript
"}

Copy the text and paste it in console.

No comments. Lack of essential data types, forcing you to make the contents of strings part of a hidden unspecified semantic (this parses as date, that parses as time, etc). Constrained by the limitations of JS floats (they aren't even bigdecimal). Excessive significant punctuation. Insignificant white space (permitting a difference between valid, and pretty-printed form). Looks like executable code and tempts you to parse it with eval.

Nothing, json's awesome. But like most data packaging schemes the finished product isn't designed with human-readability as a primary goal.

Edit: as mikegirouard points out it is much easier to read than (for example) serialized data, but still not as friendly as ini.