Errata

Status:

Verified

Type:

Technical

Reported By:

Daniel Tegründe

Date Reported:

2023-03-12

Verified by:

Andy Newton

Date Verified:

2026-05-28

Section 3. Values says:

false = %x66.61.6c.73.65   ; false

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

It should say:

false = %x66.61.6C.73.65   ; false

      null  = %x6E.75.6C.6C      ; null

Notes:

Hex values should be capitalized https://www.rfc-editor.org/rfc/rfc5234#appendix-B.1

Status:

Verified

Type:

Technical

Reported By:

Guillaume Fortin-Debigaré

Date Reported:

2023-08-11

Verified by:

Andy Newton

Date Verified:

2026-05-28

Section 6 says:

The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros are not
   allowed.

It should say:

The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros in the
   integer component beyond the units digit are not allowed.

Notes:

The original wording about leading zeros contradicts the documented ABNF grammar for JSON numbers in the following cases:
- If the integer component is equal to 0 and the fractional component exists. (Examples: 0.1, 0.001)
- In the exponent part, after the letter E or e or the optional sign. (Example: 1E01)

Status:

Verified

Type:

Technical

Reported By:

Guillaume Fortin-Debigaré

Date Reported:

2023-08-13

Verified by:

Andy Newton

Date Verified:

2026-05-28

Section 1 says:

A string is a sequence of zero or more Unicode characters [UNICODE].

It should say:

A string is a sequence of zero or more Unicode code points [UNICODE].

Notes:

Surrogate code points are not Unicode characters, as explained here: https://www.unicode.org/glossary/#surrogate_character

However, a surrogate code point outside of a surrogate pair is allowed in JSON strings both in escaped and unescaped forms according to the ABNF grammar in section 7 and the warning in section 8.2, despite an UTF-8 incompatibility for the unescaped form. In addition, the original text contradicts ECMA-404 section 9, which states: "A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. "

Status:

Verified

Type:

Editorial

Reported By:

Julian Reschke

Date Reported:

2017-12-16

Verified by:

Andy Newton

Date Verified:

2026-05-28

Throughout the document, when it says:

Internet Engineering Task Force (IETF)                      T. Bray, Ed.
Request for Comments: 8259                                    Textuality
Obsoletes: 7159                                            December 2017
Category: Standards Track
ISSN: 2070-1721

It should say:

Internet Engineering Task Force (IETF)                      T. Bray, Ed.
Request for Comments: 8259                                    Textuality
STD: 90                                                    December 2017
Obsoletes: 7159
Category: Standards Track
ISSN: 2070-1721

Notes:

Missing "STD" entry in boilerplate.

Status:

Verified

Type:

Editorial

Reported By:

Joakim Erdfelt

Date Reported:

2018-04-04

Verified by:

Andy Newton

Date Verified:

2026-05-28

Section 7 says:

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

It should say:

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-2E / %x30-5B / %x5D-10FFFF

Notes:

The solidus U+002F is listed as being escaped above, but is not excluded in the 'unescaped' sequence.

Status:

Reported

Type:

Technical

Reported By:

Bernhard E. Reiter

Date Reported:

2026-08-06

Section 11 says:

<iesg@ietf.org>

Note:  No "charset" parameter is defined for this registration.
      Adding one really has no effect on compliant recipients.

It should say:

<iesg@ietf.org>

Notes:

The first sentence of the note first repeats and 
with the second sentence contradicts the statement made a few lines earlier
in the section: `Optional parameters:  n/a` that there are no media type parameters allowed.

Disallowing the "charset" parameter is in line with the change from RFC7159 
that `Section 8.1 was changed to require the use of UTF-8 when transmitted over a network.` 
The "no effect" statement in the note was understandable for the obsolete standards 
where other encodings were allowed. 
But the rationale for it in RFC8259 is not obvious nor given. 
As argument to the contrary: Security aware applications over the last years increasingly implement 
strict whitelisting of allowed variations. Seeing a charset parameter where non is allowed will not pass
by a strictly whitelisting, compliant recipient implementation. 
And thus it will have a negative effect on those compliant recipients - which makes the note wrong. 
(If the WG would have wished for interoperability with the old standards at this point, it would
have allowed "charset"  as optional and then added a note that only "utf-8" is compatible with this RFC.)
(This errata report has some similarities with Errata-ID: 5853 but is different in that it suggests to
fully remove the wrong note.)

Suggestion: remove the wrong note (and the then superfluous repetition)

Status:

Held for Document Update

Type:

Technical

Reported By:

Lucas Tesson

Date Reported:

2023-09-20

Held for Document Update by:

Andy Newton

Date Held for Document Update:

2026-05-28

Section 7 says:

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

It should say:

string = quotation-mark *json-char quotation-mark

      json-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

Notes:

RFC 5234 Section 2.1 "Rule Naming" notes that "rule names are case insensitive". It is explained that literal text strings enclosed in quotation marks are case insensitive, and have later been clarified by RFC 7405.
In RFC 5234 Appendix B, Section B.1 "Core Rules", the rule "CHAR" is already defined such that it constitutes the core of ABNF, thus no grammar can use those names regarding the previous explanation.

The goal of this errata is to propose an alternative for the "char" rule such that RFC 8259 can provide a valid grammar regarding the ABNF RFCs.

Status:

Held for Document Update

Type:

Editorial

Reported By:

vitya-ne

Date Reported:

2025-05-28

Held for Document Update by:

Andy Newton

Date Held for Document Update:

2025-05-29

Section 14.1 says:

14.1.  Normative References

   [ECMA-404] Ecma International, "The JSON Data Interchange Format",
              Standard ECMA-404,
              <http://www.ecma-international.org/publications/
              standards/Ecma-404.htm>.

It should say:

14.1.  Normative References

   [ECMA-404] Ecma International, "The JSON Data Interchange Format",
              Standard ECMA-404,
              <https://ecma-international.org/publications-and-standards/
              standards/ecma-404/>.

Notes:

Link to ECMA-404 should be updated

Status:

Rejected

Type:

Technical

Reported By:

Vasiliy Faronov

Date Reported:

2017-12-28

Rejected by:

Andy Newton

Date Rejected:

2026-05-28

Section 12 says:

JSON is a subset of JavaScript

It should say:

JSON is nearly a subset of JavaScript

Notes:

JSON is not a subset of JavaScript: there are syntactically valid JSON texts that are not syntactically valid JavaScript. Namely, JSON strings can contain unescaped U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR characters, while JavaScript string literals cannot. Thus, a sequence of characters U+0022 U+2028 U+0022 matches this RFC's 'string' production, but does not match ECMA-262's 'Expression' production.

Status:

Rejected

Type:

Technical

Reported By:

Luca BRUNO

Date Reported:

2019-09-05

Rejected by:

Andy Newton

Date Rejected:

2026-05-28

Section 11 says:

Note:  No "charset" parameter is defined for this registration.
    Adding one really has no effect on compliant recipients.

It should say:

Note:  No "charset" parameter is defined for this registration.
    JSON text is encoded as described in RFC 8259, Section 8.1.

Notes:

Last sentence of last note of section 11 should be amended, as it introduces confusion by going against other explicit statements, like the followings:
 * RFC8259 sect. 8.1 defines that inner encoding is UTF-8
 * RFC8259 sect. 11 defines no formal (optional/required) parameters for this registered type
 * RFC6838 sect. 4.2.1 defines the common usage of a "charset" parameter as a "required" one (which isn't the case here)
 * RFC6838 sect. 4.2.1 defines that "charset" should not be used if the inner payload already transports charset information (e.g. mandatory UTF-8, which is the case here)
 * RFC6838 sect. 4.2.1 defines a "charset" parameter only for subtypes of the "text/*" hierarchy (which isn't the case here)

Status:

Rejected

Type:

Technical

Reported By:

David Golden

Date Reported:

2020-06-10

Rejected by:

Barry Leiba

Date Rejected:

2020-06-10

Section 8.1 says:

In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.

It should say:

In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark or MAY interpret a byte order mark to indicate an alternate encoding rather than treating it as an error.

Notes:

The original line is copied from previous RFCs that specifically allowed alternate encodings.  In the context of a new, UTF-8 only restriction, interoperability provisions should also address interpreting legacy formats that predate the restriction.  By omission, readers may conclude that the *only* option for a BOM is to ignore or error.
 --VERIFIER NOTES-- 
   This is asking to revisit what we have consensus on, not a report of an error in the RFC.
The working group had extensive discussions on BOMs, and chose this particular working purposefully.

Status:

Rejected

Type:

Technical

Reported By:

Maxim Iurie

Date Reported:

2023-01-13

Rejected by:

Francesca Palombini

Date Rejected:

2023-01-18

Section 3 says:

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

It should say:

      null  = %x6e.75.6c.6c      ; null without quotation marks for numeric attributes and "null" for string attributes.

Notes:

It is not clear how to encode null values in JSON.
Some are encoding all attributes as "null".
Some are encoding all attributes as null without quotation marks
Some are encoding string attributes as "null" and numeric attributes as null without quotation marks.
https://json.org is mentioning "null". ECMA 262  is mentioning "null" for string and +0F for numeric attributes. However providing zero for a number instead of null is incorrect and provides wrong results (in BI).
 --VERIFIER NOTES-- 
The original specification is clear as such, and this errata would make a change that breaks the format, and is against the original intent of the text.

Status:

Rejected

Type:

Technical

Reported By:

Guillaume Fortin-Debigaré

Date Reported:

2023-08-25

Rejected by:

Andy Newton

Date Rejected:

2026-05-28

Section 6 says:

Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.

It should say:

Note that when such software parses numbers as rational numbers in
   decimal or scientific notation, they are interoperable in the sense
   that implementations will agree exactly on their numeric values. In
   particular, when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in that
   sense.

Notes:

IEEE 754 does not consider negative zero and positive zero to be the same numeric value, even though it considers them equal. Despite this, JavaScript serializes negative zero as the JSON text "0", which contradicts the original text.

My suggested correction mentions "rational numbers in decimal or scientific notation" since it's never explicitly mentioned in the document how a number should be interpreted when parsed to maximize interoperability. This version addresses that concern at the same time.

Status:

Rejected

Type:

Technical

Reported By:

Zachary Collier (Zamicol)

Date Reported:

2023-10-11

Rejected by:

Andy Newton

Date Rejected:

2026-05-28

Section 7 says:

The representation of strings is similar to conventions used in the C family
of programming languages.  A string begins and ends with quotation marks. All
Unicode characters may be placed within the quotation marks, except for the
characters that MUST be escaped: quotation mark, reverse solidus, and the
control characters (U+0000 through U+001F).

It should say:

The representation of strings is similar to conventions used in the C family
of programming languages.  A string begins and ends with quotation marks.  All
Unicode characters may be placed within the quotation marks, except for the
characters that MUST be escaped: quotation mark, reverse solidus, and the
control characters (U+0000 through U+001F, U+007F, and U+0080 through
U+009F).

Notes:

There are 33 7-bit control characters, but the JSON RFC only listed 32 by
omitting the inclusion of the last control character in the 7-bit ASCII range,
'del.'  However, JSON is not limited to 7-bit ASCII; it is Unicode.  Unicode
encompasses 65 control characters from U+0080 to U+009F, totaling an additional
32 characters.  The section that currently reads "U+0000 through U+001F" should
include these additional control characters reading as "U+0000 through U+001F,
U+007F, and U+0080 through U+009F"

Status:

Rejected

Type:

Technical

Reported By:

Fótyék Róbert

Date Reported:

2025-10-31

Rejected by:

Andy Newton

Date Rejected:

2025-11-01

Section 4 says:

...The names within an object SHOULD be unique.

It should say:

Unknown, this contradicts the ECMA-404 specification.

Notes:

In both the ECMA-404 and the RFC 8259 specifications, it is stated that both descriptions should be considered equal. However, in RFC 8259 it is stated that names in an object should be unique, whereas in ECMA-404 it says in section 6 : "The JSON syntax does not impose any restrictions on
the strings used as names, does not require that name strings be unique..."

This seems to expose a contradiction between the two, expectedly equal specifications.
 --VERIFIER NOTES-- 
 Consensus is to reject.

see https://mailarchive.ietf.org/arch/msg/json/reBGZ98FYQeyvfi-bWkFtzJPrdk/

Status:

Rejected

Type:

Technical

Reported By:

Scott Morgan

Date Reported:

2026-04-09

Rejected by:

Andrew Newton

Date Rejected:

2026-04-13

Section 6 says:

6.  Numbers

   The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros are not
   allowed.

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

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

   Numeric values that cannot be represented in the grammar below (such
   as 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

   This specification allows implementations to set limits on the range
   and precision of numbers accepted.  Since software that implements
   IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
   available and widely used, good interoperability can be achieved by
   implementations that expect no more precision or range than these
   provide, in the sense that implementations will approximate JSON
   numbers within the expected precision.  A JSON number such as 1E400
   or 3.141592653589793238462643383279 may indicate potential
   interoperability problems, since it suggests that the software that
   created it expects receiving software to have greater capabilities
   for numeric magnitude and precision than is widely available.

   Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.

It should say:

...
TODO something like
https://github.com/adligo/ten10b_v1.adligo.org
also see
https://www.ietf.org/archive/id/draft-morgan-ten64-00.html#commentary
...

Notes:

Since JSON is based on ECMAScript now, it should be explicit in how ECMAScript's (decimal) numbers are serialized and deserialized.  It should include which algorithms should be used, when, and why.  It should be exceedingly specific about rounding, if and when rounding should ever be used!  Without being explicit, various implementations will not be able to communicate apples to apples.
 --VERIFIER NOTES-- 
 JSON is not based on ECMAScript.

See email thread: https://mailarchive.ietf.org/arch/msg/json/gucVG-EN3b2XJsKBsOJBU_6-LLI/