RFC 4627

The application/json Media Type for JavaScript Object Notation (JSON)

📅 published July 2006, from ietf

RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON) 💖

okay bestie, this is RFC 4627 🎀 It came out of the Network Working Group as Request for Comments 4627, and it's categorised as Informational. Douglas Crockford wrote it from JSON.org, and it's dated July 2006. The header doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨

Status of This Memo 🦋

So this memo is here to inform the Internet community. It is not an Internet standard of any kind, no cap. Distribution of it is unlimited 🌸

Copyright (C) The Internet Society (2006). That's the legal flex 💜

Abstract 🌈

JSON, which stands for JavaScript Object Notation, is a lightweight, text-based, language-independent data interchange format ✨ It was derived from the ECMAScript Programming Language Standard. JSON is a small set of formatting rules for portable representation of structured data, and it's giving very clean energy 🫶

1. Introduction 🦋

Alright so JSON is a text format for serializing structured data 💖 It's derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard, Third Edition [ECMA] ✨

JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays) 🎀

A string is a sequence of zero or more Unicode characters [UNICODE]. Zero is allowed, so the empty string counts 🌸

An object is an unordered collection of zero or more name/value pairs. A name is a string, and a value is a string, number, boolean, null, object, or array 💜

An array is an ordered sequence of zero or more values 🧚

The terms "object" and "array" are borrowed from JavaScript conventions 💅

JSON's design goals were to be minimal, portable, textual, and a subset of JavaScript 👑

1.1. Conventions Used in This Document 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the words you need to know, iykyk 🙈

The grammatical rules in this document are to be interpreted as described in [RFC4234] 🔥

2. JSON Grammar 🎀

A JSON text is a sequence of tokens. The set of tokens includes six structural characters, strings, numbers, and three literal names ✨

A JSON text is a serialized object or array. So the grammar looks like this:

      JSON-text = object / array

These are the six structural characters:

      begin-array     = ws %x5B ws  ; [ left square bracket

      begin-object    = ws %x7B ws  ; { left curly bracket

      end-array       = ws %x5D ws  ; ] right square bracket

      end-object      = ws %x7D ws  ; } right curly bracket

      name-separator  = ws %x3A ws  ; : colon

      value-separator = ws %x2C ws  ; , comma

Insignificant whitespace is allowed before or after any of the six structural characters 🌸

      ws = *(
                %x20 /              ; Space
                %x09 /              ; Horizontal tab
                %x0A /              ; Line feed or New line
                %x0D                ; Carriage return
            )

2.1. Values 🦋

A JSON value MUST be an object, array, number, or string, or else it has to be one of the following three literal names:

      false null true

The literal names MUST be lowercase 🙈 No other literal names are allowed.

         value = false / null / true / object / array / number / string

         false = %x66.61.6c.73.65   ; false

         null  = %x6e.75.6c.6c      ; null

         true  = %x74.72.75.65      ; true

2.2. Objects 💖

An object is written as a pair of curly brackets wrapping zero or more name/value pairs, which are also called members. A name is a string. A single colon comes after each name to separate it from its value, and a single comma separates a value from the name that follows it. The names within an object SHOULD be unique ✨

      object = begin-object [ member *( value-separator member ) ]
      end-object

      member = string name-separator value

2.3. Arrays 🧚

An array is written as square brackets wrapping zero or more values, which are also called elements. The elements are separated by commas 🎀

      array = begin-array [ value *( value-separator value ) ] end-array

2.4. Numbers 💜

Numbers look a lot like they do in most programming languages. A number has an integer component that may begin with an optional minus sign. That integer can be followed by a fraction part, an exponent part, or both 🔥 Octal and hex forms are not allowed. Leading zeros are not allowed either.

A fraction part is a decimal point followed by one or more digits.

An exponent part begins with the letter E, in upper or lowercase, and it may be followed by a plus or minus sign. The E and the optional sign are then followed by one or more digits.

Numeric values that cannot be represented as sequences of digits, like Infinity and NaN, are not permitted 💀

         number = [ minus ] int [ frac ] [ exp ]

         decimal-point = %x2E       ; .

         digit1-9 = %x31-39         ; 1-9

         e = %x65 / %x45            ; e E

         exp = e [ minus / plus ] 1*DIGIT

         frac = decimal-point 1*DIGIT

         int = zero / ( digit1-9 *DIGIT )

         minus = %x2D               ; -

         plus = %x2B                ; +

         zero = %x30                ; 0

2.5. Strings 🌈

Strings look a lot like conventions in the C family of languages. A string begins and ends with quotation marks. Every Unicode character can go inside the quotes except the ones that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F) 🫶

Any character may be escaped. If the character is in the Basic Multilingual Plane (U+0000 through U+FFFF), it can be written as a six-character sequence: a reverse solidus, then the lowercase letter u, then four hexadecimal digits that encode the code point. The hex letters A through F can be upper or lowercase. For example, a string containing only one reverse solidus can be written as "\u005C" 💅

There are also two-character escape sequences for some popular characters, so that same single reverse solidus can be written more compactly as "\\" ✨

To escape an extended character that isn't in the Basic Multilingual Plane, you use a twelve-character sequence that encodes a UTF-16 surrogate pair. For example, a string containing only the G clef character (U+1D11E) can be written as "\uD834\uDD1E" 🎶

         string = quotation-mark *char quotation-mark

         char = unescaped /
                escape (
                    %x22 /          ; "    quotation mark  U+0022
                    %x5C /          ; \    reverse solidus U+005C
                    %x2F /          ; /    solidus         U+002F
                    %x62 /          ; b    backspace       U+0008
                    %x66 /          ; f    form feed       U+000C
                    %x6E /          ; n    line feed       U+000A
                    %x72 /          ; r    carriage return U+000D
                    %x74 /          ; t    tab             U+0009
                    %x75 4HEXDIG )  ; uXXXX                U+XXXX

         escape = %x5C              ; \

         quotation-mark = %x22      ; "

         unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

3. Encoding 🌸

JSON text SHALL be encoded in Unicode. The default encoding is UTF-8 💖

Since the first two characters of a JSON text will always be ASCII characters [RFC0020], you can work out whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) just by looking at the pattern of nulls in the first four octets 🔍

        00 00 00 xx  UTF-32BE
        00 xx 00 xx  UTF-16BE
        xx 00 00 00  UTF-32LE
        xx 00 xx 00  UTF-16LE
        xx xx xx xx  UTF-8

4. Parsers 🧚

A JSON parser transforms a JSON text into another representation 🦋 A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions 💜

An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range of numbers. An implementation may set limits on the length and character contents of strings 🎀

5. Generators 💅

A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar 🔥

9.1. Normative References ✨

okay bestie, this is the reading list the spec leans on hardest 📚💅 Every one of these is a document the RFC is built on, so they're all in here, no skipping 🫶

Author's Address 🎀

Douglas Crockford JSON.org EMail: douglas@crockford.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). ✨

📦 where this page comes from