Testing JSON Formatter Offline Functionality

If you want a JSON formatter that works offline, the important question is not just whether it can pretty-print JSON. It is whether parsing, validation, and formatting happen locally in the browser after the page has loaded, without sending your payload to a server.

For most browser-based formatters, the core logic is local because it relies on native JavaScript APIs such as JSON.parse() and JSON.stringify(). What you actually need to test is everything around that core: whether the page still works when the network is disabled, whether any request is made while you paste data, and whether errors stay readable when the connection disappears.

What "Offline JSON Formatter" Should Mean

A credible offline claim should hold up under all of these checks:

• Local-only processing: The JSON payload stays on the device while you format, validate, expand tree views, or copy output.
• Formatting still works with no connection: Once the page is open, valid JSON should still pretty-print and invalid JSON should still produce local error messages.
• Fresh reload behavior is honest: If the app shell is cached, it should reopen offline. If it is not cached, the tool should at least avoid pretending it is fully offline-capable.
• Status indicators are not enough: navigator.onLine is only a hint. A real offline test checks actual network requests, not just an "offline" badge in the UI.

Fast Verification Checklist

A search visitor usually wants a quick answer: "Can I trust this formatter offline?" This workflow gets you there quickly.

1. Open the formatter while online, then open the browser's Network panel and clear the request log.
2. Paste a known valid sample and confirm the expected output first. A tiny minified payload is enough:

   {"env":"prod","retryCount":3,"features":{"offline":true,"prettyPrint":true},"items":[1,2,3,4]}

3. Switch browser network throttling to Offline.
4. Repeat the same actions with valid JSON, invalid JSON, and a fake sensitive sample. Formatting and validation should still work.
5. Watch for any new fetch, XHR, WebSocket, analytics, or logging requests when you paste, format, or view the parsed tree.
6. While still offline, do a hard reload. If the page fails to reopen, that does not necessarily mean the formatter logic is remote. It usually means the app shell is not cached for full offline reopening.

That distinction matters. There are really two different promises: works offline after loading and can be reopened offline from a fresh load. A good test separates them.

Current Browser Workflow

Current desktop browsers make offline testing straightforward:

• Chrome and Edge: Open DevTools, go to the Network panel, then choose Offline from the throttling dropdown next to Disable cache.
• Firefox: Open the Network Monitor and use the Throttling dropdown. Current Firefox builds still include an Offline preset there.

When you do this, prefer the network log over any in-app connectivity flag. Browser vendors explicitly note that navigator.onLine uses heuristics and can report misleading positives.

Key Areas and Test Cases

Testing Valid JSON

Start with normal formatting behavior. If the tool cannot handle everyday payloads locally, the offline claim is irrelevant.

• Minified payloads: A real formatter should turn one-line JSON into readable output without touching the network.
• Simple objects and arrays: { "key": "value" }, [1, 2, 3], [null, false]
• Nested structures: Objects containing arrays, arrays containing objects, and deeper combinations.

  {
    "user": {
      "id": 1,
      "name": "Alice",
      "roles": ["admin", "editor"],
      "details": {
        "age": 30,
        "isActive": true
      }
    },
    "products": [
      { "name": "Laptop", "price": 1200 },
      { "name": "Mouse", "price": 25 }
    ]
  }

• Various data types: Strings, numbers, scientific notation, booleans, and null.

  {
    "string": "Hello, World!",
    "numberInt": 42,
    "numberFloat": 3.14,
    "numberScientific": 1.23e-4,
    "booleanTrue": true,
    "booleanFalse": false,
    "nullable": null
  }

• Strings with escapes: Quotes, backslashes, newlines, tabs, and Unicode escapes should all survive a format round-trip.

  {
    "escapedString": "This string has a \"quote\" and a newline\nand a tab\t and unicode \u20AC (Euro sign)."
  }

• Top-level primitive JSON values: "hello", 123, true, and null are valid JSON values and should parse correctly.
• Empty structures: {} and [] should format cleanly.

Testing Invalid JSON

A good formatter should not just format valid JSON. It should reject invalid input locally and explain why.

• Missing commas:

  {
    "key1": "value1"
    "key2": "value2"
  }

• Incorrect braces or brackets: Mismatched or missing delimiters.

  [
    { "item": 1
  ]

• Unquoted keys: JSON requires keys to be double-quoted strings.

  {
    key: "value"
  }

• Single-quoted strings: JSON requires double quotes.

  {
    "key": 'value'
  }

• Trailing commas: They are valid in modern JavaScript literals, but invalid in strict JSON.

  {
    "key1": "value1",
    "key2": "value2",
  }

• Incorrect keywords: Using True, undefined, or NaN should fail immediately.

  {
    "status": True
  }

• Invalid string escapes: Backslashes not followed by a valid escape character.

  {
    "key": "String with invalid escape \x"
  }

Testing Edge Cases

These cases usually expose hidden dependencies, poor performance, or confusing UX:

• Very large JSON: Test with MBs of data to check browser memory pressure and editor responsiveness.
• Whitespace-only input: The tool should fail clearly, not silently clear the editor or show a misleading success state.
• Pasted text from other tools: Smart quotes, hidden characters, and editor-added line endings should produce understandable errors.
• JSON with comments: While not part of strict JSON, users paste it often. The tool should either reject it clearly or support a documented cleanup path.

  {
    /* This is a comment */
    "data": 123 // This is another comment
  }

Testing Privacy and Network Leakage

This is the part many "offline" tools skip. Use obviously fake sensitive data and confirm that nothing is transmitted while you work.

• Paste a sample like the one below while offline and while the Network panel is recording.

  {
    "customerEmail": "alice@example.com",
    "apiKey": "sk_test_REDACTED",
    "internalNote": "Use fake secrets when testing privacy boundaries."
  }

• Confirm there is no new request to an API, logging endpoint, or analytics collector after paste.
• Confirm secondary actions also stay local, including tree expansion, copy helpers, and validation buttons.
• If the tool surfaces parse errors, make sure the error UI is generated locally instead of depending on a remote service.

Testing Error Reporting

When invalid JSON is provided, the formatter should provide clear feedback.

• Does it clearly indicate that an error occurred?
• Is the message understandable to a developer reading raw JSON?
• Does it provide the line number and ideally the column number where parsing failed?
• Is the problematic part of the input highlighted or otherwise easy to find?

Common False Positives

A formatter can appear offline-friendly while still depending on the network in subtle ways. Watch for these traps:

• Already-open tab passes, fresh reload fails: The formatting engine is local, but the page is not cached for true reopen-offline use.
• The UI says offline, but requests still fire: This usually happens when the app trusts navigator.onLine too much.
• Formatting works, but extras break: Remote fonts, icon sets, telemetry, or bug-reporting hooks can still fail noisily when the connection is gone.
• Cached assets hide a network dependency: A second visit may look fully offline only because JavaScript and CSS were cached earlier. Clear cache and repeat the test if you need the strict answer.

Automated vs. Manual Testing

The parsing logic is easy to unit test. The offline claim is not. You usually need both automated coverage and a browser-level manual pass.

• Automated: Test wrapper functions around JSON.parse and JSON.stringify, indentation options, line and column extraction, and large-input handling.
• Manual: Test offline mode in real browsers, inspect the request log, and verify the editor, tree view, copy buttons, and error UI still work without connectivity.

Conclusion

Testing a JSON formatter offline is less about indentation and more about trust. A real offline formatter keeps parsing local, stays usable with the network disabled, exposes clear errors, and does not leak payloads through background requests. If you separate works after load from can reopen from a fresh offline load, you will get a much more honest answer about how offline the tool really is.