JSON as a Boundary: Why JavaScript Loses Information on Purpose

At first glance, JSON feels like JavaScript.

You write something like:

{
  "name": "Rishi",
  "age": 24
}

and it looks almost identical to a JavaScript object.

It’s easy to assume they are basically the same thing.

But they’re not.

That small difference — between looking similar and actually being the same — is where most confusion about JSON begins.

JSON Is Not JavaScript

A JavaScript object is a data structure inside your program.

JSON is just text.

That distinction matters more than it seems.

When you write:

const user = {
  name: "Rishi",
  greet() {
    console.log("hi")
  }
}

you’re creating something that contains both:

data + behavior

But JSON only cares about one of those:

data

So when you convert this object into JSON, something subtle happens.

Serialization Is a Filter, Not a Copy

When you call:

JSON.stringify(user)

you might expect a full representation of the object.

But what you actually get is:

{"name":"Rishi"}

The function greet disappears completely.

This is not a limitation. It’s intentional.

JSON is not trying to represent everything in JavaScript. It’s trying to represent only what can be safely shared across systems.

So instead of copying the object, JSON.stringify performs a kind of filtering process.

It keeps only what fits inside the JSON format and discards the rest.

The Limits of JSON

JSON supports only a small set of values:

• string
• number
• boolean
• null
• array
• object

That’s it.

There is no concept of:

• undefined
• functions
• symbols
• BigInt

So when JavaScript encounters these values during serialization, it has to make a decision.

And that’s where things get interesting.

Why undefined Disappears in Objects

Consider this:

JSON.stringify({
  name: "Rishi",
  age: undefined
})

The result is:

{"name":"Rishi"}

The age property is completely removed.

Why?

Because JSON has no representation for undefined.

And objects are flexible structures. Removing a key doesn’t break anything.

So JavaScript simply omits it.

Why undefined Becomes null in Arrays

Now compare this:

JSON.stringify([1, undefined, 3])

The result is:

[1, null, 3]

This feels inconsistent at first.

Why not remove the value here as well?

Because arrays are different from objects.

Objects are about keys.

Arrays are about positions.

If JavaScript removed the undefined, the array would become:

[1, 3]

Now the meaning of index 1 has changed.

To preserve the structure, JavaScript keeps the position and replaces the value with null.

Not because null is the same as undefined, but because it is the closest valid value JSON can represent.

Why JSON Doesn’t Support undefined at All

You might ask:

Why not just include undefined in JSON?

Something like:

[1, undefined, 3]

The problem is that JSON is not meant for JavaScript alone.

It’s designed to work across:

• Python
• Java
• Go
• many other systems

Most of these languages don’t have an undefined concept.

So including it would make JSON:

hard to parse
inconsistent across languages

Instead, JSON defines a smaller, universal set of values that every system can understand.

It becomes a kind of “lowest common denominator” for data.

Data Without Behavior

This leads to an important realization.

JavaScript objects can contain:

data + behavior + structure

JSON strips that down to:

data only

No functions.

No prototypes.

No execution logic.

Just values and structure.

This is what makes JSON portable.

Why This Design Matters

JSON sits at a boundary.

Inside your application, you work with rich objects.

Outside your application — across networks, storage, APIs — you need something stable and predictable.

So the transformation looks like this:

object → JSON → object

And during that transformation, JavaScript intentionally loses information.

Not because it can’t keep it, but because it shouldn’t.

A Better Way to Think About JSON

Instead of thinking:

“JSON is just JavaScript objects as strings”

It’s more useful to think:

“JSON is a contract between systems”

It defines what kind of data is safe to send, store, and reconstruct.

And everything that doesn’t fit that contract gets removed or transformed.

What Looks Like a Limitation Is Actually a Feature

At first, behaviors like removing functions or converting undefined to null feel like quirks.

But they’re not accidents.

They are the result of a design choice:

Make data predictable across different environments, even if it means losing some information.

Once you see JSON as a boundary — not a mirror of JavaScript — these behaviors start to feel less surprising and more inevitable.