CF Model ↔ JSON Schema Converter

What this tool does

The converter translates between the two places a content model usually lives: an AEM content fragment model (.content.xml) and a JSON Schema used by the apps that read the content. It works in three ways:

• Model → JSON Schema: paste a model and get a draft 2020-12 JSON Schema with the right types, formats, lengths, patterns, options and required fields.
• JSON Schema → Model: paste a schema (draft 07, 2019-09 or 2020-12) and get a .content.xml ready to deploy, or open it in the CF Model Generator to keep editing. Anything that doesn’t translate exactly is listed as a note.
• Compare: paste both and see, field by field, what matches, what differs and what exists on one side only.

It works for AEM as a Cloud Service and AEM 6.5, and runs entirely in your browser.

When to use it

• Starting a headless project: front-end teams often design the content shape as a JSON Schema first. Turn it into a model instead of re-typing it in the model editor.
• Sharing the model with app teams: give them a schema for validation, mock data and type generation (for example with quicktype or json-schema-to-typescript).
• Keeping two definitions in sync: when the model and the schema are maintained separately, Compare shows exactly what drifted.
• Reviewing model changes: a JSON Schema in a pull request is easier to read than FileVault XML.

How to use it

1. Pick a direction with the tabs at the top, or press Try an example.
2. Model → JSON Schema: paste the model’s .content.xml. Keep Add AEM details ticked if you might convert the schema back. Copy or download the schema.
3. JSON Schema → Model: paste the schema and choose the AEM version and configuration (the /conf folder). Read the notes, then copy or download the .content.xml, or press Edit in the CF Model Generator to adjust fields, add tabs or download an installable package.
4. Compare: paste the model on the left and the schema on the right. Differences are listed first.

How fields map

Content fragment field	JSON Schema
Single-line text	string, with maxLength and pattern from validation
Multi-line text	string with contentMediaType (text/html, text/markdown or text/plain)
Number (integer / fraction)	integer / number, with minimum
Boolean	boolean
Date and time (date, time, both)	string with format date, time or date-time
Enumeration as a dropdown	string with enum
Enumeration as checkboxes	array of string with enum and uniqueItems
Tags	array of string (tag IDs)
Content reference	string, format: uri-reference (a path)
Fragment reference	string, format: uri-reference (a fragment path)
Any field set to multiple	array of the field’s type
Required	listed in required
Field label and description	title and description

Settings that JSON Schema can’t express go into an x-aem object on each property: the AEM field type, tab, root path, allowed models, option labels, and options such as translatable or unique. JSON Schema tools ignore keywords they don’t know, and the converter uses them to rebuild the model exactly.

Reading a schema without x-aem

• Field types are inferred from type, format, contentMediaType and enum.
• $refs within the document, allOf, and nullable types (["string", "null"] or anyOf with null) are resolved.
• Property names that aren’t valid in AEM (speaker-names) are renamed (speaker_names).
• A nested object becomes a fragment reference. Create a model for it, and set that model as the allowed model.
• Keywords with no model equivalent, such as maximum, const or if/then, are ignored, and each one is noted.

Limits

• Remote $refs (to other files or URLs) aren’t followed. Combine the schema into one file first.
• Content fragment models can’t express every JSON Schema rule. The notes list everything that was dropped.
• Fields the CF Model Generator keeps “as imported” (unusual field types) aren’t included in the schema.
• The schema describes the fields you edit. The JSON that AEM’s GraphQL API or the Sites API returns adds its own wrappers, such as _path, _variation and { html, plain, json } for multi-line text.