JSON.parse creates Number values before the reviver sees them. A long integer can therefore be rounded even though every original digit remains in the JSON text. The reviver’s third context argument solves a narrower problem: when a property is still an unmodified primitive, context.source exposes the exact source span for that value. A careful reader must keep the parsed value, the original token and the application’s chosen replacement type separate.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their values and event logs are stated so each conclusion can be checked.
eduKateSG · Websites
Find your next learning step
Use the routes to follow child-first reviver order, identify when source is present, recover deliberate integers, inspect strings and literals, handle earlier mutations, and verify feature support without treating source text as automatically trusted data.
ROUTE 1 · CHAPTERS 1–3
Build the first model
Name the input, state, conversion or predicate before following user-visible results.
ROUTE 2 · CHAPTERS 4–5
Trace the decisive branch
Work the accepted path and the nearest boundary case with original examples.
ROUTE 3 · CHAPTERS 6–8
Change one premise
Rebuild the mechanism when state, value, realm, timing or object kind changes.
ROUTE 4 · CHAPTERS 9–10
Handle limits and failures
Keep abrupt completion, availability and application limits visible.
ROUTE 5 · CHAPTERS 11–12
Verify and explain
Use a decisive fixture, changed-context check and concise final account.
Chapter contents
Build the first model · Chapters 1–3
1. Separate the token from the parsed Number
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
6. Keep decimal and exponent policy explicit
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
CHAPTER 1 OF 12 · Build the first model
1. Separate the token from the parsed Number
The short answer is that JSON parsing converts a numeric token to a Number before reviver execution, while context.source can retain the token’s exact characters. Chapter 1 focuses on separate the token from the parsed number. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Parse {“id”:9007199254740993} and record both the rounded Number and source text 9007199254740993. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for separate the token from the parsed number is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change the token to 9007199254740992 and compare the case that is exactly representable. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Source fidelity does not make the ordinary Number value exact retroactively. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Log typeof value, value, context.source and the replacement independently. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of separate the token from the parsed number should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that each reviver call receives key, current value and a fresh context object in addition to its this holder. Chapter 2 focuses on receive the third reviver argument. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Use a regular function to log key, value, context and Object.keys(context). Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for receive the third reviver argument is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Replace it with an arrow function and explain why the lexical this no longer exposes the holder. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The context argument does not replace the holder relationship used for deletion and replacement. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Assert argument count, key order and holder identity in a controlled fixture. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of receive the third reviver argument should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 3 OF 12 · Build the first model
3. Require an unmodified primitive for source
The short answer is that context.source is supplied when the parse record still matches the holder’s current value and that value is primitive. Chapter 3 focuses on require an unmodified primitive for source. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Visit an untouched numeric property and observe its exact token. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for require an unmodified primitive for source is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. During an earlier sibling callback, replace a later primitive before its visit and observe the changed source availability. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: An object or array callback does not receive a source string merely because its children came from text. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Check Object.hasOwn(context,’source’) rather than assuming an undefined property means the same thing. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of require an unmodified primitive for source should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that reviver internalization visits nested properties before the object or array that contains them, then finally visits the artificial root key. Chapter 4 focuses on follow children before their parent. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Parse a nested invoice and log amount before invoice before the empty root key. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for follow children before their parent is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Return a replacement object for amount’s parent and trace the final root. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Source belongs to a primitive’s own visit; it is not a shortcut around child-first traversal. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Keep an ordered event list with key, depth, source presence and returned value. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of follow children before their parent should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 5 OF 12 · Trace the decisive branch
5. Recover a deliberate integer as BigInt
The short answer is that an application can use a verified integer token from context.source to construct BigInt without passing through the rounded Number. Chapter 5 focuses on recover a deliberate integer as bigint. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. For the id token 9007199254740993, check an integer grammar and return BigInt(context.source). Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for recover a deliberate integer as bigint is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change the token to 1.25 or 1e3 and apply an explicit policy instead of blindly constructing BigInt. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: A source token’s validity as JSON does not establish that the field is semantically an integer identifier. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Gate recovery by property meaning and a documented token grammar. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of recover a deliberate integer as bigint should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that numeric source may use a fraction or exponent, so applications must decide whether to preserve text, use decimal arithmetic or accept Number semantics. Chapter 6 focuses on keep decimal and exponent policy explicit. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Parse {“rate”:1.2300e2} and compare source 1.2300e2 with Number 123. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for keep decimal and exponent policy explicit is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change the token to -0 and retain its source sign while checking Object.is on the Number. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: BigInt is not a general replacement for JSON decimals and exponent notation. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Record token class, chosen numeric model and any scale or precision rule. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of keep decimal and exponent policy explicit should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that for an untouched primitive string, context.source contains the quoted JSON token including escape spelling, while value is the decoded String. Chapter 7 focuses on read string source as json text. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Parse {“letter”:”\u0061″} and compare source with value a. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for read string source as json text is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change the token to the literal JSON string “a” and obtain the same value with different source. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Different escape spellings can denote the same String and should not become different identities without a reason. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Display source with an escaping-aware inspector so quotes and backslashes remain visible. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of read string source as json text should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that true, false and null are primitive parsed values and can carry their exact source tokens when unmodified. Chapter 8 focuses on handle booleans and null as primitives. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Parse one property of each class and log source. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for handle booleans and null as primitives is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change an earlier callback so it replaces a later null with a string before that visit. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Source access does not turn a literal into an authorization or schema decision. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Validate field type and application meaning after observing the token. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of handle booleans and null as primitives should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 9 OF 12 · Handle limits and failures
9. Let earlier callbacks change later evidence
The short answer is that because reviver callbacks can mutate their holder, a callback for one property can alter the value another parse record later expects. Chapter 9 focuses on let earlier callbacks change later evidence. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. For {“a”:1,”b”:2}, let a’s callback set this.b=9 before b is visited. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for let earlier callbacks change later evidence is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Remove the mutation and restore b’s source token 2. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: The original JSON text still contains 2, yet the later callback is correctly about the holder’s current 9. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Capture mutation events before interpreting the context object. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of let earlier callbacks change later evidence should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 10 OF 12 · Handle limits and failures
10. Distinguish deletion from source recovery
The short answer is that returning undefined still deletes the property after the callback, regardless of whether context.source was available. Chapter 10 focuses on distinguish deletion from source recovery. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Delete a primitive secret field after logging its exact token. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for distinguish deletion from source recovery is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Return null instead and retain the property with a different value. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Observing source does not preserve a property whose reviver result is undefined. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Assert own-property presence in the final object, not just the callback log. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of distinguish deletion from source recovery should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
The short answer is that runtimes can differ in availability, so a production path should detect a source property with a separating numeric fixture. Chapter 11 focuses on feature-detect source-aware parsing. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Parse a long integer and observe whether the context owns source. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for feature-detect source-aware parsing is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Run on a runtime without the feature and choose a documented parser or transport fallback. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Re-parsing rounded values or stringifying them cannot reconstruct discarded digits. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. Record runtime version and the exact detection fixture. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of feature-detect source-aware parsing should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
CHAPTER 12 OF 12 · Verify and explain
12. Explain value, source and replacement in order
The short answer is that a complete account states the token, parsed value, source-eligibility condition, reviver policy and final property value. Chapter 12 focuses on explain value, source and replacement in order. Begin with the original JSON token, parsed primitive value, holder and property key, child-first visit order, parse record, whether the holder value is still SameValue to its parsed value, context object, optional source property, reviver replacement and final root. Writing those facts first prevents a familiar label or final console line from replacing the operation that actually decides the result.
Worked example. Report a long integer recovered as BigInt only after integer-field validation. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the call, then record each conversion, lookup, check or state transition in order. Stop the trace when an abrupt completion occurs; later effects are not inferred from what normally would have happened.
A useful first-principles question for explain value, source and replacement in order is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. Change the field to a decimal rate and rebuild the policy. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: Do not say context.source makes JSON numbers arbitrary precision by itself. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. End with the original text, event log, final types and one trust limit. Capture returned values and thrown error classes, but also preserve the event log that led to them. A test that asserts only the last value can pass even when an earlier conversion, constructor, iterator close, atomic operation or realm boundary was wrong.
A concise final explanation of explain value, source and replacement in order should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, engine message wording or an unstated timing assumption. That form is short enough for revision and precise enough for a code review or debugging note.
Contents · Previous chapter · Return to the Websites subject guide
Frequently asked questions
When is context.source available?
For an unmodified primitive whose current holder value still matches the parsed value.
Do objects and arrays get source text?
No source property is supplied for those object values.
Can context.source recover exact long integer digits?
It preserves the token, which an application may deliberately validate and convert to BigInt.
Does the reviver see the source before Number conversion?
No. The parsed Number already exists; source is separate evidence.
What does an escaped string source contain?
The quoted JSON token, including its escape spelling.
Does source text make data trusted?
No. Schema, range, origin and authorization checks still belong to the application.
Continue through the verified reading routes
Start with the wider system
The Gold Standard of Websites · The Gold Standard of Education | Learning That Transfers into Life · How X Works hub
Compare the closest mechanisms
JSON revivers from child values to the final root · parseInt prefix parsing and complete conversion · toJSON conversion before replacer decisions · JSON.rawJSON primitive validation and string quoting
Choose the next lesson by reader job
Use the subject root to move from this focused mechanism to the next verified question. Follow a specialist link when its preconditions match your code; return to the wider hub when the next task belongs to a different system.
Authoritative sources and evidence checks
ECMAScript 2027: JSON.parse · ECMAScript 2027: JSON Parse Records · ECMAScript 2027: InternalizeJSONProperty · ECMA-404: The JSON Data Interchange Syntax
The ECMAScript specification defines the language algorithms. A cited proposal draft is used where it contains the integrated Stage 4 text. Controlled runtime checks can confirm an implementation’s current behaviour, but feature availability and performance still depend on the runtime version and environment.