Can a JSON Document Be Just a Number, Boolean, or Null?

Yes. A complete JSON document can be just 29, true, false, null, or a double-quoted string such as "hello". Objects and arrays are also valid root values, but neither kind of wrapper is necessary for a document to qualify as JSON.

Three separate checks matter when you work with these inputs: whether the text is valid JSON, whether a particular parser accepts its root value, and whether the receiving application permits that value. Keeping those checks separate helps you correct the actual mismatch. The examples below show expected parsing results, explain which quotation marks belong to the JSON text, and provide a practical workflow for inspecting input and output in a JSON formatter.

One value can be a complete JSON document

The value-based JSON grammar allows one JSON value to form a complete document, with permitted whitespace around it. That value can be an object, array, string, number, boolean, or null. Strings, numbers, booleans, and null are the primitive types discussed here.

For example, the entire contents of a document can be:

29

There is no missing object around this number. Likewise, a document containing only null contains a value; it is different from empty input. A standalone string is also complete when its required double quotation marks are present.

Think of the root as the value submitted for parsing. An application might require an object at that position, but first consider the syntax question: does the input contain one permitted JSON value?

Surrounding whitespace does not add another value. JSON permits spaces, horizontal tabs, line feeds, and carriage returns as whitespace. Consequently, true still contains one boolean value. An input containing only whitespace has no value, while true false contains two consecutive values. Neither satisfies the requirement for one complete JSON document.

This distinction gives you a useful first inspection: look for the value itself before deciding whether braces or brackets are needed. Add structure when the payload requires it, rather than assuming every JSON root must be a container.

Standalone primitives: examples and expected results

Each call below supplies a separate, complete JSON text to JavaScript’s JSON.parse. The comments show the expected result and identify its type where helpful.

JSON.parse('29');       // number: 29
JSON.parse('true');     // boolean: true
JSON.parse('false');    // boolean: false
JSON.parse('null');     // null
JSON.parse('"hello"');  // string: "hello"

The number needs no brackets or braces. The boolean literals and null use lowercase spelling. The string example includes double quotation marks within the text being parsed.

What should you enter in a formatter?

Paste the JSON text itself. For the first example, enter 29. For the last example, enter "hello", including its double quotes. The surrounding JSON.parse(...) expression belongs to the JavaScript example; it is not part of the JSON document.

Inspect one example at a time. Placing all five sample values together in the input would create a sequence of values, which is a different input from any individual example above.

These examples also distinguish a present value from missing input. Both false and null are complete JSON values. If a receiving form or application reports either as missing, inspect that application’s requirements and handling separately. Replacing the value or adding a wrapper before understanding the requirement could change a payload that was already valid JSON.

Quoted text changes the resulting type

Quotation marks affect the value produced by parsing. A number and a string containing the same digits are different results. The same distinction applies to null and a string containing the letters null.

JavaScript expression	Expected result	Resulting type
JSON.parse('29')	29	Number
JSON.parse('"29"')	"29"	String
JSON.parse('null')	null	Null
JSON.parse('"null"')	"null"	String

There are two quotation layers in these JavaScript examples. In JSON.parse('"29"'), the outer single quotes delimit the JavaScript string passed to the parser. The inner double quotes belong to the JSON text. The parser therefore receives "29", which represents a JSON string.

In JSON.parse('29'), the outer JavaScript quotes still delimit the argument, but the JSON text contains only the digits 29. That input produces a number.

The null examples follow the same pattern. Unquoted null is the JSON literal. Double-quoted "null" is a string whose characters spell the literal’s name. Quotation marks in the result column make the string’s type visible; they distinguish text from the unquoted value.

When moving an example from JavaScript source into a formatter, identify the JSON text before copying. Removing the JSON double quotes from "29" changes its type. Adding them to 29 also changes its type. Choose the representation required by the receiving application, and preserve that choice when editing or formatting.

Invalid literals, empty input, and extra values

Accepting standalone primitives does not mean accepting arbitrary unquoted text. The literal names true, false, and null must be lowercase. The unquoted tokens undefined, NaN, and Infinity are not valid JSON values.

The following inputs are invalid JSON. The table describes their syntax problems without assigning a particular JavaScript exception type or error message.

JSON input	Why it is invalid
True	It does not use the required lowercase boolean spelling.
undefined	This unquoted token is not a JSON value.
NaN	This unquoted token is not a JSON value.
Infinity	This unquoted token is not a JSON value.
Empty input	No JSON value is present.
true false	Two consecutive values are present.
hello	The unquoted word is not a JSON value.
'hello'	JSON strings require double quotes.

Permitted whitespace around a value is different from additional content:

JSON.parse(' true '); // boolean: true

Here, surrounding spaces leave one value to parse. In true false, whitespace separates two values; it does not turn them into one document. Determine the intended payload before changing its structure.

Why do single quotes appear in valid JavaScript examples?

The single quotes in JSON.parse('"hello"') delimit the JavaScript argument. They are not the quotation marks used by the JSON string inside that argument. If you enter 'hello' directly into a JSON formatter, those single quotes are part of the submitted text, and the input does not satisfy JSON’s string quotation rule.

When diagnosing a rejection, compare the exact input with these patterns. Check capitalization, quotation marks, absent values, and extra values before investigating restrictions on otherwise valid roots.

Where the object-or-array expectation came from

The expectation that every JSON document must begin with an object or array has a historical basis. Earlier JSON grammar required an object or array at the root. The later value-based grammar permits a single value, including a primitive.

That earlier requirement explains why an object-or-array rule may appear in documentation or tooling. It should not be presented as the rule for all JSON documents.

What should you check when a primitive is rejected?

Read the tool’s documented JSON standard and parsing mode. Look for an explicit root restriction, and determine whether rejection happens while reading the JSON or during a separate application check.

For example, rejection of 29 alone does not establish that the number is malformed JSON. Investigate whether the tool requires an object or array. By comparison, True has a syntax problem regardless of a root restriction: its spelling does not match the lowercase JSON boolean literal.

A useful diagnostic report includes the exact input, the documented mode, and the stage that rejected it. Those details make a report such as “this tool rejects a standalone number” more actionable than “numbers are invalid JSON.” If the documentation does not explain primitive roots, ask whether the restriction belongs to the parser or to the application using it.

Valid JSON can still fail an application's contract

Parsing and application validation answer different questions. Parsing concerns whether text can be read as JSON under the parser’s rules. An application’s contract concerns whether the resulting value has the required structure and content. A successful parse does not settle that second question.

Consider an explicitly hypothetical endpoint whose complete requirement is an object containing a numeric field named value. The standalone input 29 parses successfully, but its root is a number. It therefore fails this hypothetical object requirement.

Under that stated contract, the corresponding object would be:

{"value":29}

Wrapping changes the payload structure: the root becomes an object, and the number appears in its value field. This structure matches the hypothetical requirement because that requirement explicitly calls for it.

The field’s type still matters. This input contains a string instead:

{"value":"29"}

Both examples are JSON, but only the first matches the numeric-field requirement described above.

When should you add a wrapper?

Verify the required root shape, field name, and field value type before wrapping a primitive. If the receiving application expects a standalone number, introducing an object changes what you send. If it expects an object with different fields, an arbitrary value wrapper does not establish compliance.

Keep three possible problems visible while troubleshooting: invalid JSON syntax, a parser restriction on the root, and application rejection of a parsed value. Correcting spelling addresses a syntax problem. Selecting a documented parsing mode may address a parser restriction. Changing payload structure requires checking the receiving contract.

Inspect a primitive and preserve its meaning

Use a JSON formatter to compare the submitted text with the displayed root value, the output, and any reported error. Begin with a small example whose expected result is clear, then apply the same inspection to the payload you need to diagnose.

1. Enter the JSON text directly. Use 29, true, null, or "hello" without a surrounding JSON.parse(...) call.
2. Inspect the root value. Compare pairs such as 29 and "29". Confirm that the representation distinguishes a number from a string.
3. Compare input and output. Look for changes to quotation marks, root structure, and numeric text. Preserve the original input so you can inspect any differences.
4. Locate the reason for rejection. Check invalid literals, empty input, and extra values first. Then investigate documented parser restrictions or application validation.
5. Check the receiving contract. Successful formatting does not establish that another application accepts the payload’s root or field types.

Does successful formatting guarantee numeric precision?

No. Valid numeric syntax and preservation of the original numeric token are separate checks. Successful parsing or formatting alone does not establish that numeric precision is preserved throughout the workflow.

If numeric fidelity matters, retain the original input and compare its numeric text with the output. Check what the formatter documents about number handling, and ask what representation the receiving application requires. A textual comparison can reveal a rewritten token, but it cannot establish how every later stage handles the value.

Avoid adding quotation marks merely to get a number through a tool. Changing 29 to "29" produces a string and changes the payload’s type. Agree on the required representation, then inspect whether the workflow preserves it.

A useful inspection result answers several concrete questions: What text entered the formatter? What root value did it display? What text came out? Which requirement, if any, rejected it? Those observations connect a formatting result to the mismatch you need to resolve.