By Ronnie Mbuqe
JSON distinguishes numbers from strings. The value 12 is numeric, while the value '12' represented with JSON double quotes is text.
An application must validate and deliberately convert inputs where necessary. Displaying similar characters does not make the underlying types interchangeable.
The characters 007 can be a reference that must never become 7
A booking reference can look numeric without being a quantity. If the exact characters matter, converting 007 into the number 7 destroys part of the identifier. A successful parse alone does not tell an application whether it chose the right type.
We will inspect one small JSON object and separate syntax from meaning. By the end you should be able to explain why a reference, a guest count and an absent note need different treatment.
Read a tiny payload using its agreed field meanings
The bookingRef value is a string, so its leading zeroes remain. guests is a number because it describes a count. note is explicitly null, which is a different structure from omitting the field entirely.
{
"bookingRef": "007",
"guests": 3,
"note": null
}
The API must define what null and omission mean. In an update, omission might preserve an existing note while null might clear it. JSON supplies the representation; it does not invent that business policy.
Change the reference to an unquoted 007 and you no longer have a valid JSON number. Change it to the valid number 7 and the syntax may parse, but the reference meaning is still lost. There are therefore two separate checks: can we parse this, and does it meet the contract?
What type should preserve the exact reference 007: string or number?
This checks a prediction about the worked example. It does not run server code, contact an API or change a booking.
String. A number represents a quantity; an identifier may need its exact original characters. Valid syntax still needs field-level validation.Read the explanation without the checker
String. A number represents a quantity; an identifier may need its exact original characters. Valid syntax still needs field-level validation.
List what your own application should do when note is missing, null or an empty string. If those outcomes are unclear, the contract needs work before code is connected.
Can valid JSON still contain an invalid booking?
A JSON parser checks the document format.
Trace the explanation
It does not know whether a departure date precedes arrival or a user may access a record. Separate parsing, schema validation and business rules rather than treating them as one check.
Source and further reading: MDN Web Docs
Practical examples: JSON
API
An API can return a booking as named fields such as bookingId, status and checkInDate. The browser parses that text into an object and displays selected values. A valid JSON document can still contain an invalid date or forbidden status, so application validation remains necessary.
User
A user profile may contain a name, preferences and a list of roles. Sensitive fields should not be included merely because JSON can carry them. The API chooses the smallest safe representation required by the calling screen.
Settings
Applications often save settings such as theme, language or notification choices as JSON. Flexible structure is useful, but undocumented field changes can break older versions, so stable names and sensible defaults form part of the contract.
App
A mobile app can cache a JSON response for offline viewing, then request newer data when connectivity returns. It must distinguish absent fields, explicit null values and old cached information instead of treating all three as the same situation.
The number 007 and the text '007' are not the same kind of value
An identifier may contain leading zeroes that must survive unchanged. Treating it as a number can discard that meaning. JSON distinguishes numbers, strings, booleans, null, arrays and objects, but a valid document does not tell you whether a particular field should be an identifier or an amount.
A schema or documented contract adds that meaning: field names, expected types, required values and allowed ranges. A booking reference encoded as text can stay exactly as supplied, while a guest count can be validated as a suitable number.
A response contains 6 records with 4 fields each. How many field values are represented if each record has all fields?
Trace the explanation
6 × 4 = 24 field values. A field may contain null, text, a number or another structure; counting values does not establish that their types or meanings are correct.
Source and further reading: MDN Web Docs
Why should an API send an identifier as text?
Identifiers are labels, not quantities to add. Leading zeros may matter, and very large integer values can exceed a client's exact numeric range.
A reference such as 00123 should retain its identity through every system. Choosing a string avoids accidentally changing a label into an arithmetic value.
Missing, null and empty can lead to three different actions
In an update request, omitting a middle-name field might mean 'leave it unchanged'. Sending null might mean 'clear it', and an empty string might be forbidden. Those meanings do not come automatically from JSON; the API must define them.
Before connecting two systems, test those cases deliberately. Also remember that JSON has no built-in date type. An agreed date string needs a format and a time-zone policy where time is involved. Otherwise two systems can read the same characters and place an event on different calendar days.
If JSON parses successfully, is every value safe to save?
No. Parsing establishes syntactic structure. Validate types, ranges, permissions and the business meaning before accepting the data; never treat a parsed value as automatically trusted.
Questions about JSON Explained Simply
Is JSON a programming language?
No. JSON is a data format, not a programming language. You cannot write logic or instructions in it; it only describes structured data, the way a shipping label describes a package's contents without being able to move the package itself.
Is JSON hard to learn?
No. The basic idea is simple: names and values are grouped together clearly.
What is the difference between an object and an array?
A JSON object groups named properties inside curly braces. An array is an ordered list of values inside square brackets.
Can JSON contain dates?
JSON has no special date type. Dates are usually sent as strings in an agreed format, which the receiving application then parses.
Why do APIs sometimes fail after a property is renamed?
Clients depend on the agreed response shape. Renaming or removing a property can be a breaking contract change unless clients are updated or the API is versioned safely.
Is JSON secure?
The format itself is neither secure nor insecure. Security depends on how data is transported, validated, authorised, logged and displayed.
Read JSON as a structured value, not a paragraph
JSON is a text format for representing structured data. Curly braces group named properties into an object; square brackets hold an ordered list; strings use double quotes; numbers, booleans, and null have their own forms. This predictable structure makes it easier for two applications to exchange information.
{
"customerId": 104,
"name": "Lindi",
"active": true,
"preferredLanguages": ["en", "xh"],
"address": null
}
In this example, customerId is a number, name is text, active is a Boolean, preferredLanguages is an array of strings, and address has no value represented by JSON null. A receiving program still needs to decide what each field means and whether it is required.
Common pitfalls
- Property names and strings require double quotes; single quotes are not valid JSON string delimiters.
- A trailing comma after the last property or array item makes ordinary JSON invalid.
- The number
12 and the string "12" are different types. null is not the same as a missing property or an empty string.- Valid JSON can still contain the wrong data, missing fields, or values outside the range an application accepts.
Validate at the boundary
When an application receives JSON, parse it and then validate its meaning. Check required fields, types, lengths, allowed values, and permissions. Do not trust client-side validation alone; requests can be sent directly to the server. Avoid logging complete payloads if they may contain personal or confidential information.
When debugging an integration, compare the expected schema with the actual response. A property renamed from inStock to available may leave the JSON valid but break code that expects the old name. Schema and contract tests can catch that mismatch earlier.
Further reading: Introducing JSON; RFC 8259: The JSON Data Interchange Format.
A payment amount arrives as the string "500" rather than the number 500. Why should the contract specify which is expected?
One reasoned response
Different representations can affect validation, arithmetic and compatibility. A documented contract prevents each caller from guessing how to interpret the same field.
Source and further reading: MDN Web Docs
Read the shape, not just the values
JSON represents data using objects, arrays and simple values. An object groups named properties; an array stores an ordered list. The difference matters because code that expects one object may fail if the server returns a list, and code that expects a number may fail if the value is actually text.
Example response
{
"bookingId": 4821,
"guest": {
"name": "Example Guest",
"emailVerified": true
},
"nights": 3,
"notes": null,
"extras": ["parking", "breakfast"]
}
Here, bookingId and nights are numbers, emailVerified is a Boolean, notes is explicitly null, and extras is an array of strings. The guest is a nested object. The sample uses fictional details and should not be used as a real guest record.
Common pitfalls
- JSON property names and string values use double quotes.
- A trailing comma after the final item is invalid in standard JSON.
null, true and false are not quoted strings.- Do not assume a field is always present or has the expected type; validate external data.
- Never treat JSON as safe merely because it parses. Validate permissions and business rules separately.
When an integration fails, inspect the raw response and compare its actual structure with the schema your code expects. The first mismatch is often more useful than changing several parsing statements at once.
Sources
Sources and further reading
A closer lookA reference number is not always a number
A service sends {"reference":"00127","guests":2}. The reference is text so its leading zeros survive, while guests is a count. Changing the reference to the number 127 loses formatting information.
Work through the distinction
Choose types by meaning, not appearance. JSON has no dedicated date type, so a date string also needs an agreed format and timezone convention. Validate the agreed schema before treating arbitrary data as a complete booking.
Which value should preserve its leading zeros?
Choose an answer to see feedback. You can try again.
Show the answer and explanation
The reference string. Choose types by meaning, not appearance. JSON has no dedicated date type, so a date string also needs an agreed format and timezone convention. Validate the agreed schema before treating arbitrary data as a complete booking.