JSON 3 was a polyfill designed to provide `JSON.parse` and `JSON.stringify` functionality for older JavaScript environments that lacked native JSON support, specifically targeting ECMAScript 5 and earlier platforms (e.g., Internet Explorer 6-8). It adheres closely to the ECMAScript 5.1 specification, notably employing a recursive descent parser to avoid reliance on `eval`, a common security concern in early JSON implementations. The library's core differentiator was its robust, specification-compliant parsing and stringification for these legacy environments. However, it explicitly deviates from the spec regarding date serialization: it does not define `Date#toISOString()` or `Date#toJSON()`, instead handling date objects internally during `stringify()` operations, serializing them as simplified ISO 8601 strings. This approach aimed to preserve CommonJS compatibility and avoid polluting native prototypes. The project, last updated to version 3.3.3, is now explicitly deprecated and unmaintained. Developers are strongly advised against using it in new projects and should migrate existing applications to leverage the native `JSON` object available in all modern JavaScript environments. Its release cadence was irregular towards the end, as native JSON support became widespread. It was part of the BestieJS family, focusing on cross-platform support and specification adherence.
npm install json3Verified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to include json3 as a global polyfill via a script tag and use its `JSON.stringify` and `JSON.parse` functions, including a reviver, and the `JSON3.noConflict` method.
Remove json3 from your project. Rely on the native `window.JSON` object, which is universally available and performs better in all modern JavaScript environments. If targeting extremely old browsers (e.g., IE6-8) is an absolute requirement, carefully assess the risks of using unmaintained software.
Be aware of this specific behavior when serializing `Date` objects. If specific ISO 8601 formats are strictly required, consider manually transforming dates into strings before `stringify` operations, or ensure your target environments natively support `Date.prototype.toJSON` if you are using native JSON.
Thoroughly test JSON serialization behavior across all target environments, especially regarding `Date` objects. If such overriding is problematic, consider conditionally loading the polyfill only when truly necessary, or adopt a different strategy for handling JSON in older browsers (e.g., server-side rendering for legacy clients).
Prioritize migrating away from json3. If immediate migration is impossible, thoroughly audit your application's use of JSON to minimize exposure, and consider isolating its usage to less sensitive parts of your application, acknowledging the inherent risks of unmaintained software.
Ensure the `json3` script is included in your HTML `<head>` or at the beginning of your JavaScript bundle, before any code that attempts to use `JSON.parse` or `JSON.stringify`. Verify that the script loaded without errors (check browser developer console).
json3 is intended to be a global polyfill. Include it via a `<script>` tag in your HTML. If using a module bundler, ensure it processes the script in a way that exposes `JSON` globally (e.g., using `script-loader` for Webpack or similar global injection methods).
If a specific ISO 8601 date string format is required, manually transform `Date` objects into the desired string format before passing them to `JSON.stringify`. For example, `JSON.stringify({ date: myDate.toISOString() })`.No dependency data recorded yet.