Hacker News Reader

Comment by bsmth | Hacker News Reader

I can imagine if it's deeply nested data, your markup might get complex, but the structure of the HTML doesn't have to mirror the JSON. There's other examples here which might illustrate more how this can look: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

View on HN

Thank you. I was looking at a generic way to pass configuration data to custom elements where I cannot know the shape in advance, since another dev can have different requirements. I support data attributes for simple types but i was wondering if allowing arbitraty json objects via other means could be feasible.

Since JSON is a subset of JavaScript, you can just use a script element, and including the json mime type certainly doesn't hurt:

    <script type="application/json" id="myJSONData">
      {
        "name": "John Doe",
        "age": 30
      }
    </script>

    <script>
      const data = JSON.parse(document.getElementById('myJSONData').textContent);
      console.log(data.name + " is " + data.age); // John Doe is 30
    </script>

Note: The JSON data must exist literally within the script element. If you try using a src attribute to request it from elsewhere, the response will not be available via textContent or any other mechanism [0], and at that point you just need to fetch/ajax/xhr it.

[0] https://stackoverflow.com/questions/17124713/read-response-o...

About embedding JSON in a script tag, I recently read an article on the risk of a closing </script> tag within the JSON that could break it.

Safe JSON in script tags: How not to break a site - https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not...

As with all untrusted content, depending on where the JSON string comes from, sanitizing the output is worth considering.

Great article! I suppose a similar (yet different) precaution would be needed in data-* attributes or any other part of an HTML document.

That article was pretty complicated; I appreciate the historical understanding but frankly web legacy is too complex to bother with "why" too much, in the end so many things just don't make sense and are historical accidents.

Here's another take, just a short list of replacements. Interestingly, "&" is also escaped: https://pkg.go.dev/encoding/json#HTMLEscape

That's a helpful summary of what's necessary to make JSON safe to embed in script tags.

I agree the "why" is too long of a story, an accumulation of supposedly logical decisions that led up to the ball of quirks. It's too much to remember. Exactly the kind of thing that should be delegated to a specialized function made and maintained by experts.

Reply on news.ycombinator.com