120

I am new to JSON and JavaScript objects.

  • Can someone please explain the differences between JSON and JavaScript object?
  • What are their uses?
  • Is one better than the other? Or does it depend on the situation?
  • When to use which one, in what situation?
  • Why was JSON created in the first place? What was its main purpose?
  • Can someone give examples of when one should use JSON rather than a JavaScript object and vice versa?
Barry Michael Doyle
  • 9,333
  • 30
  • 83
  • 143
Pheap
  • 2,349
  • 4
  • 18
  • 13

3 Answers3

174

First you should know what JSON is:

  • It is language agnostic data-interchange format.

The syntax of JSON was inspired by the JavaScript Object Literal notation, but there are differences between them.

For example, in JSON all keys must be quoted, while in object literals this is not necessary:

// JSON:
{ "foo": "bar" }

// Object literal:
var o = { foo: "bar" };

The quotes are mandatory on JSON because in JavaScript (more exactly in ECMAScript 3rd. Edition), the usage of reserved words as property names is disallowed, for example:

var o = { if: "foo" }; // SyntaxError in ES3

While, using a string literal as a property name (quoting the property name) gives no problems:

var o = { "if": "foo" };

So for "compatibility" (and easy eval'ing maybe?) the quotes are mandatory.

The data types in JSON are also restricted to the following values:

  • string
  • number
  • object
  • array
  • A literal as:
    • true
    • false
    • null

The grammar of Strings changes. They have to be delimited by double quotes, while in JavaScript, you can use single or double quotes interchangeably.

// Invalid JSON:
{ "foo": 'bar' }

The accepted JSON grammar of Numbers also changes, in JavaScript you can use Hexadecimal Literals, for example 0xFF, or (the infamous) Octal Literals e.g. 010. In JSON you can use only Decimal Literals.

// Invalid JSON:
{ "foo": 0xFF }

There are some buggy implementations (Firefox 3.5+, IE8+, json2.js) where octal literals are wrongly allowed, e.g. JSON.parse('01') should produce a SyntaxError.

DuncanSungWKim
  • 3,774
  • 1
  • 14
  • 11
Christian C. Salvadó
  • 807,428
  • 183
  • 922
  • 838
  • 57
    +1 Good answer but could do with emphasising the subsetting: any valid JSON declaration is also a valid JavaScript declaration, but not all valid JavaScript declarations are JSON declarations. – Daniel Earwicker Oct 20 '10 at 08:26
  • 1
    Would also be helpful to demonstrate the only way we'd ever see JSON in a Javascript file; i.e. inside a string. – Lightness Races in Orbit Dec 09 '11 at 18:12
  • @CMS describes it perfectly above, but i would say you can pretty much tell the difference by what JSON actually stands for... that is JavaScript Oject "Notation"! – Alex Oct 20 '10 at 08:20
  • 5
    @DanielEarwicker: not all valid JSON is necessarily a valid object expression in javascript: http://timelessrepo.com/json-isnt-a-javascript-subset certain unicode whitespace characters are valid in json strings but not in javascript. – Eamon Nerbonne Nov 18 '13 at 21:58
  • 1
    @EamonNerbonne - as noted on that page, that is extremely easy to fix in the only scenario where it (very rarely) causes an issue. – Daniel Earwicker Nov 19 '13 at 09:14
  • 1
    It's a potential crashbug issue in that if an attacker embeds `\u2028` characters and your (valid) json serializer doesn't escape them (as isn't necessary), any pages that literally include a json literal and evaluate it as a JS object may encounter exceptions. It's easy to fix; at the serializer level, but it's a pain that's it's not a proper subset - then you could reliably embed (valid) json in javascript without risk. It's mostly just annoying, nothing more - granted :-). – Eamon Nerbonne Nov 19 '13 at 20:39
28

JSON is a string representation of an object. It is an interoperable serialization format. It is not tied only to javascript. For example there are JSON serializers for .NET allowing you to serialize/deserialize .NET objects.

So it's just a format allowing you to convert from objects to string and back which is convenient if you want to transfer them over the wire.

It is very close to javascript object representation and if you simply eval() a JSON string you will get the corresponding object.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 3
    Don't let Crockford hear you say that... – nickf Oct 20 '10 at 08:34
  • 4
    @nickf, the Crockford's json2.js library does just that, `eval` after some "regex validation", it doesn't do anything of *parsing* :P. In fact, even his *own library* has some deviations from [his own RFC](http://www.ietf.org/rfc/rfc4627.txt?number=4627)!, for example, json2.js can wrongly "parse" Octal literals, e.g.: `JSON.parse("01")`... I find it funny :P – Christian C. Salvadó Oct 20 '10 at 08:46
  • @CMS Well I guess Doug would object to the phrase "simply `eval()`" then... (sans the regex validation and so on) – nickf Oct 20 '10 at 10:52
  • so if i just write a program in JavaScript that needs to use object, i should not use JSON since I am not sending the object to other place? – Pheap Oct 20 '10 at 19:22
  • 1
    [Not all JSON strings are valid JS](http://timelessrepo.com/json-isnt-a-javascript-subset) – Bergi Nov 01 '12 at 15:58
  • Which of them should I pass to JSON.stringify() – Fortune Nov 03 '16 at 17:40
2

JSON is a data interchange format, which just happens to look like a subset of YAML or JavaScript code you can execute and get an object back. A JavaScript object is just an object in JavaScript.

With JSON being a data interchange format you can exchange structured data in a textual form with it. It is pretty decoupled from JavaScript by now. JavaScript object allow you to create and work with structured data during the execution of a JavaScript program.

Joey
  • 344,408
  • 85
  • 689
  • 683