JSON-LD
JSON-LD is ordinary JSON with one extra field, @context, that says what the other fields mean. The context maps each short field name onto a globally unique identifier, normally a URL published by whoever defined the vocabulary, so a system that has never seen the data before can still work out what it is being told.
Plain JSON says how data is written down, not what it means. A field called name could hold a person, a company or a product, and two systems can both emit valid JSON while disagreeing about every field in it. That gap is normally closed by a written agreement between the two parties, which works for one integration and stops working when a credential issued in one country has to be read by a verifier in another that nobody spoke to in advance.
JSON-LD closes it inside the document. The @context maps each short field name onto a globally unique identifier, so the field stays readable for a human and becomes unambiguous for a machine. None of the values change, and a receiver that does not recognise the vocabulary can still read the document as ordinary JSON and ignore the rest. JSON-LD 1.0 became a W3C Recommendation on 16 January 2014, and version 1.1 followed on 16 July 2020.
The W3C Verifiable Credentials Data Model 2.0 is built on it. Every credential opens with a @context whose first value is the shared credentials vocabulary, so the issuer, the subject, the validity dates and the status information mean the same thing everywhere, and any further vocabulary supplies the fields that one specific credential type needs.
Signing a linked-data document is a choice between two mechanisms. An enveloping proof such as a JWT signs the bytes exactly as they are, so anything that reorders or reformats them on the way breaks the signature. An embedded Data Integrity proof signs a canonical form instead, defined by RDF Dataset Canonicalization, which is what lets the signature survive being written out again somewhere else.
It is not one of the EUDI Wallet credential formats. The Architecture and Reference Framework names SD-JWT VC and mdoc, and neither of them uses JSON-LD, so an organisation issuing into the European wallet will never meet a @context. JSON-LD earns its place where data has to travel beyond the ecosystem that defined it: W3C verifiable credential deployments, product passports and supply chain data.
The same format is also how a website tells a search engine what a page is about, with the @context pointing at schema.org rather than at a credentials vocabulary. The processing rules are identical in both cases, which makes structured data the easiest place to see what a context actually buys you.
Read the full explanation
This page gives the short definition. Our explainer shows what it means in practice: who is involved, how it works and what changes for your organisation.
JSON-LD explainedIs JSON-LD one of the EUDI Wallet credential formats?
No. The Architecture and Reference Framework names SD-JWT VC and mdoc, and neither of them is a JSON-LD format, so a wallet or verifier built for the European rules needs no JSON-LD processor at all.
That is a scoping decision rather than a verdict on the format. Both of the formats the framework names have a fixed shape, one signature mechanism and no document a verifier has to go and fetch before it can check anything, which is what a phone and a response time measured in milliseconds reward. JSON-LD answers a different question, namely how data keeps its meaning outside the ecosystem that defined it, and organisations working across both worlds usually end up supporting both.
What is the difference between JSON-LD and plain JSON?
Nothing in how the document is written: every JSON-LD document is valid JSON, and software that only needs one field out of it can treat it as such. The difference is the @context, which maps each field name onto a globally defined identifier, so the meaning of the data travels with the document instead of living in a specification the two parties had to agree on beforehand.
The extra machinery only matters when a document is expanded into its full form or canonicalized for signing, steps a verifier reading a single claim never performs. The real cost sits elsewhere: the context has to be available, and a verifier that fetches it while verifying has put a network call and a remote server inside a security decision. Deployments pin the contexts they accept and ship them with the software instead.