{“lastseen”:”2025-10-22T16:39:39″,”description”:”This year, JSON module imports became baseline ‘newly available’, meaning they’re implemented across browser engines.\\n \\n \\n import data from ‘.\/data.json’ with { type: ‘json’ };\\n \\n \/\/ And\u2026\\n \\n const { default: data } = await import(‘.\/data.json’, {\\n with: { type: ‘json’ },\\n });\\n\\nI’m glad JavaScript has this feature, but I can’t see myself using it in a browser environment, other than small demos. It comes down to the behaviour differences with this:\\n \\n \\n const response = await fetch(‘.\/data.json’);\\n const data = await response.json();\\n\\nHere’s why\u2026\\n\\n## Error handling\\n\\nWith a static import:\\n \\n \\n import data from ‘.\/data.json’ with { type: ‘json’ };\\n\\nIf the above fails, it takes the whole module graph down with it. Because of this, I’d never use this pattern with some third-party JSON, as I’d want to be able to provide a fallback if the third-party service fails.\\n\\nBut `import()` allows exactly that:\\n \\n \\n try {\\n const { default: data } = await import(url, {\\n with: { type: ‘json’ },\\n });\\n } catch (error) {\\n \/\/ Fallback logic\\n }\\n\\nThis is pretty good. Although the `fetch()` alternative:\\n \\n \\n try {\\n const response = await fetch(‘.\/data.json’);\\n const data = await response.json();\\n } catch (error) {\\n \/\/ Fallback logic\\n }\\n\\n\u2026allows much more introspection in event of a failure. There’s `response.status`, or you can use `response.text()`, meaning you still have the source if JSON parsing fails. Maybe that doesn’t matter in all cases.\\n\\nI think the bigger issue is\u2026\\n\\n## Caching and garbage collection\\n\\nWhen you import a module (be it JS, WASM, CSS, or JSON), it’s cached for the lifetime of the environment (e.g. a page or worker), even if the result is a network or parsing failure. All imports for a given specifier \\u0026 type return the same module.\\n\\nThis is generally a good thing, as it means your JS module returns the same objects every time, and state can be shared across all importers. But if you’re doing something like:\\n \\n \\n const { default: results } = await import(‘\/api\/search?q=whatever’, {\\n with: { type: ‘json’ },\\n });\\n\\n\u2026then you have a memory leak, because each set of search results will live in the module graph for the life of the page. That isn’t the case with `fetch()`, where returned objects can be garbage collected once they’re out of reference.\\n\\nThe same applies to cases like:\\n \\n \\n let { default: largeData } = await import(‘\/large-data.json’, {\\n with: { type: ‘json’ },\\n });\\n \\n const someSmallPart = largeData.slice(0, 10);\\n largeData = null;\\n\\nIf the above used `fetch()`, then the data other than `someSmallPart` could be garbage collected. But with `import()`, the whole `largeData` object remains in memory for the life of the page.\\n\\n## When should JSON modules be used?\\n\\nIt makes sense to use JSON module imports for local static JSON resources where you need all\/most of the data within. Particularly since bundlers can understand JSON imports, and bundle the object with other modules. That isn’t possible with `fetch()`, unless you use some pretty hacky plugins.\\n\\nIn server code, I might import `package.json` to get the version number. However, I wouldn’t do this with frontend code, as it’s wasteful to bundle all of `package.json` just to get a single value \u2013 bundlers don’t perform tree-shaking of individual object keys.\\n\\n**Update:** Jed points out that esbuild has an option at allows you to import JSON as if each top level key is individually exported, and in this case it will tree-shake. You could make a fairly trivial plugin to make the same work for Rollup\/Vite. It still requires you to use the right kind of import, though.\\n\\nGenerally, I’d write a Vite\/Rollup plugin to extract just the data I needed at build time (with Vite, the define option is handy).\\n\\nI’m glad this feature exists, but it should be used with care, and not as a blanket replacement for `fetch()`ing JSON.”,”published”:”2025-10-22T01:00:00″,”modified”:”2025-10-22T01:00:00″,”type”:”jakearchibald”,”title”:”Importing vs fetching JSON”,”source”:””,”references”:””,”id”:”JAKEARCHIBALD:A496D7960199E35FDA15EAD6611BA94F”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/jakearchibald.com\/2025\/importing-vs-fetching-json\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-10-22T16:39:39″,”description”:”This year, JSON module imports became baseline ‘newly available’, meaning they’re implemented across browser engines.\\n \\n \\n import data from ‘.\/data.json’ with { type: ‘json’…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,161,13,33,7,11,5],"class_list":["post-22722","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-jakearchibald","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n