Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of best-selling jQuery in Action and Rails 3 in Action. He spends most of his time hacking on open source—his main projects, along with others, like Thor, Handlebars and Janus—or traveling the world doing evangelism work. He can be found on Twitter as @wycats.
jQuery 1.4 and Malformed JSON
January 15th, 2010
Today, we released jQuery 1.4, a mostly backward compatible release with a few minor quirks. One of these quirks is that jQuery now uses the native JSON parser where available, rejecting malformed JSON.
This probably sounds fine, except that by malformed JSON, we mostly mean:
{foo: "bar"} |
Because this is valid JavaScript, people have long assumed it was valid JSON, and a lot of hand-coded JSON is written like this. Thankfully, JSON automatically generated by Rails does not have this problem, so most of you guys should not have an issue here.
If you have server-side JSON that can’t be quickly fixed in the transition to jQuery 1.4, you can use the compatibility plugin, which tries to patch a number of small incompatibilities, or you can use this workaround:
$.ajax({url: "/url", dataType: "json", success: function(json) { // do something with json } }); // becomes $.ajax({url: "/url", dataType: "text", success: function(text) { json = eval("(" + text + ")"); // do something with JSON } }); |
Essentially, this is what jQuery used to do to evaluate JSON, so with these small changes you can get the old behavior.
Again, though, you should probably be modifying your busted server-side code to stop sending malformed JSON!

Bob Aman, Posted January 15, 2010, 2:38 am
Does this new JSON behavior in jQuery 1.4.0 work with Prototype 1.6.x loaded at the same time? I’ve been having all kinds of problems with things that use the native JSON parser when Prototype is in play.
Josh Powell, Posted January 15, 2010, 2:53 am
What makes this malformed JSON?
{foo: “bar”}
christopher, Posted January 15, 2010, 3:11 am
@bob there is at least one critical issue with the latest prototype and native json.
Check this: https://prototype.lighthouseapp.com/projects/8886/tickets/730-prototypejs-breaks-firefox-35-native-json
Brian LeRoux, Posted January 15, 2010, 3:32 am
Tho most certainly not the best practice you may want to change that hack to:
json = eval(‘(‘ + text + ‘)’)
…if the user wants to deserialize/unmarshall to an object. Otherwise they’ll just get the first property. Bonus points for checking if JSON object exists and if it does use the JSON.parse method (much safer).
August Lilleaas, Posted January 15, 2010, 3:43 am
Why is that JSON invalid? Is it the space after the colon?
James Padolsey, Posted January 15, 2010, 4:34 am
@August, It’s invalid because there are no quotes around foo. See http://json.org/
wycats, Posted January 15, 2010, 4:42 am
Thanks for pointing out the issue with parens. With regard to your second point, you misunderstand the point of my post. jQuery already *natively* uses JSON.parse internally, which breaks malformed JSON that is valid JavaScript. This hack allows you to deserialize such malformed JSON.
Neeraj Singh, Posted January 15, 2010, 9:21 am
{ foo: “bar” } is a valid JavaScript object but it is not a valid JSON.
{ “foo” : “bar” } is a valid JSON.
Also note that JSON demands double quotes. Following two examples are ,once again, valid JavaScript objects but they are not valid JSON.
{ ‘foo’: “bar” }
{ “foo” : ‘bar’ }
@August Lilleaas : space is not an issue. Both of the following two examples are valid JSON.
{ “foo”:”bar” }
{ “foo” : “bar” }
Josh Powell, Posted January 15, 2010, 10:44 am
Requires double quotes? Are we sure on that one? That is awful for transmitting HTML.
Consider:
{‘foo’:”}
against
{“foo”:”"}
Josh Powell, Posted January 15, 2010, 10:48 am
Requires double quotes? Are we sure on that one? That is awful for transmitting HTML.
Consider:
{‘foo’:'<div id=”foo”></div>’}
against
{“foo’<div id=\”foo\”></div>”}
Brian LeRoux, Posted January 15, 2010, 2:08 pm
Oh, I got the point of the post. Just thought I’d try and make it more clear and failed miserably. =P
"Cowboy" Ben Alman, Posted January 15, 2010, 2:24 pm
You could also specify this before including jQuery 1.4:
window.JSON = null;
"Cowboy" Ben Alman, Posted January 15, 2010, 2:25 pm
Oops… wish there was a “preview” mode.. I meant this:
<script type=”text/javascript” language=”javascript”>window.JSON = null;</script>
Neeraj Singh, Posted January 15, 2010, 2:58 pm
I ended up writing a full blog on this subject building on the previous comment. http://www.neeraj.name/blog/articles/895-handling-json-parsing-natively-in-jquery-1-4-and-what-changed-from-jquery-1-3
Tj, Posted January 15, 2010, 4:40 pm
your json var is global lol shesh :P
Jiraya, Posted January 15, 2010, 11:48 pm
JSON was supposed to be JavaScript Object Notation. Hate this gibberish of making double quotes obligatory, takes all of the shine away from just being a simple data format.
malsup, Posted January 17, 2010, 9:24 am
> window.JSON = null;
No, that won’t help. jQuery 1.4 pre-validates the json text via regEx before invoking the native parser.
Paul Irish, Posted January 19, 2010, 12:43 pm
A good resource if you are lazy is: http://www.jsonlint.com
Which will ambiguously bitch at you about malformed JSON.
Enjoy
Telemachus, Posted January 19, 2010, 7:47 pm
@Josh: Check out the JSON website (http://json.org/):
An object is { string: value } and a string is defined as “a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.”
AlmostAlive, Posted January 19, 2010, 11:39 pm
Making double quote obligatory makes the JSON data format even simpler. In JavaScript they are optional, so you have three possible code paths: double-quoted, single-quote, or not quoted at all. Making it mandatory means now you only have one code path.
BurningHellfire, Posted February 16, 2010, 7:13 pm
This change is totally bullshit. The whole beauty of JSON was that you return a string and it just gets evaled. Why do I want to waste the user’s resources to fucking parse a string to make sure it is valid first? I’m the one sending the string, it’s my own goddamn fault if it’s invalid. What exactly is the benefit of being forced to use more quotes? It just eats bandwidth unnecessarily. FUCK THAT!
thomas, Posted April 3, 2010, 7:14 am
I’m fucked ^^
I just adjusted my entire code to json, today I update to 1.4 and none of my json strings work ^^ damn quotes :D
Phil, Posted May 28, 2010, 1:29 am
I have to say that I agree this change is total bullshit. Changing working functionality just to make your life easier coding the library is never a good idea.
This is just the final nail in the coffin for me JQuery is the Visual basic of JavaScript frameworks.
Kirby L. Wallace, Posted June 14, 2010, 3:47 pm
Wow. That turned nasty real fast.
Pardon me, but did he say there was a compatibility plugin you can use if you simply insist on bastardising the JSON standard? I’m not real into JSON (yet – but getting there), so I may be wrong.
Nikita, Posted July 7, 2010, 4:49 am
Use http://www.jsonlint.com/ to validate your JSON.
Zoe, Posted July 19, 2010, 2:26 am
@Phil: Requiring valid markup is bullshit? I don’t suppose you’re an IE user? What utter rubbish, that a browser demand valid HTML to display your pages correctly! ;-)
@Josh Powell: Single quotes are valid in HTML (http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2), so this would be valid:
{“foo”:”"}
Zoe, Posted July 19, 2010, 2:29 am
Oops, comment system stripped my html, but you get the idea.
One last try for good measure:
{“foo”:”<div id=’foo’>”}