Known issues of ArduinoJson 7

This page lists the known issues and limitations of ArduinoJson 7.

They are all compromises made to reduce the size of the library and are, therefore, unlikely to be fixed in the future.

Known issue 1: the parser isn’t strict

ArduinoJson’s parser is relatively lax and accepts some invalid inputs. For example, it doesn’t reject malformed UTF-16 surrogate pairs, like \ud83d\ud83d.

For that reason, you should not use ArduinoJson to validate JSON documents.

Known issue 2: keys containing NUL characters gets truncated

ArduinoJson 7 doesn’t not support keys containing NUL characters (ASCII code 0, or \u0000).

If you try to insert a key containing a NUL character, the key will be truncated.

I added support for NULs at some point but ended up removing it because it was too expensive in terms of code size.

Known issue 3: the string-to-float conversion is not perfect

ArduinoJson 7’s string-to-float conversion is good but not perfect.

For example, if the input is "0.123", you’ll get 0.1230000000000001.

You can find details about this algorithm in my article Lightweight float to string conversion.

Known issue 4: the float-to-string conversion is not perfect either

ArduinoJson 7’s serializes 1.7976931348623147e308 into "1.797693135e308". The rounding is correct, but the value exceeds double’s range. This can be an issue because when we deserialize the document, we get inf.

Known issue 5: a JsonDocument is limited to 255, 64K, or 4M nodes depending on the architecture

ArduinoJson 7 uses integers instead of pointers to locate the nodes in the JsonDocument. The width of the integers depends on the CPU architecture.

CPU architecture	Bits for node id	Max nodes
8-bit	8	255
32-bit	16	65635
64-bit	32	4294967294

This should be enough for most applications, but if you need more, you can change the width of the node id by setting ARDUINOJSON_SLOT_ID_SIZE to the desired number of bits.