OGraf is an open specification for web-based broadcast graphics. It defines how a graphic is packaged, described, controlled and supplied with data, so the same graphic can move between compatible broadcast systems instead of being locked to one vendor.
That short definition also answers a common question: is OGraf simply HTML, CSS and JavaScript? The visual part often is. What makes it OGraf is the standard contract around those web technologies.
OGraf in plain English
Traditional broadcast graphics systems often use their own template format, data model and control commands. A template created for one system may need to be rebuilt before another renderer can use it. OGraf approaches the problem with an open, web-based format.
The official EBU OGraf project describes OGraf as an open specification for HTML-based graphics used in live television and post-production. Version 1 of the Graphics specification is stable. The goal is interoperability between graphics, rendering systems and control systems.
Create the graphic once, then use it in multiple compatible renderers.
What makes an OGraf graphic different from ordinary HTML?
A normal web page can contain the same visual building blocks, but it does not necessarily tell a broadcast controller how to operate it. An OGraf package adds a predictable structure and machine-readable information.
- A Web Component runtime: the graphic exposes a defined interface to the renderer.
- An OGraf manifest: a
.ograf.jsonfile describes the graphic package, entry point, resolution, actions and related metadata. - A data definition: valid JSON Schema describes editable fields, default values and operator controls.
- Standard actions: the controller can load, play, advance, update and stop the graphic through a known lifecycle.
- Packaged assets: fonts, images, JavaScript and CSS travel with the graphic instead of depending on an editor installation.
The OGraf Graphics specification defines these requirements in detail. That structure is the special part: not a new animation language, but a common agreement between the editor, controller and renderer.
The four parts of an OGraf workflow
1. Editor
The editor is where the graphic is designed. In Falcon Graphics, this is the browser workspace with layers, a visual viewport, keyframes, timelines and OGraf Data fields.
2. Controller
The controller is the operator interface or automation system. It chooses the graphic, enters values such as a presenter name or score, and sends play, next, update and stop commands.
3. Server
An OGraf server manages available graphics and routes control messages. A complete workflow can use a dedicated server, while a self-contained HTML export can also be loaded directly by systems that already render web templates.
4. Renderer
The renderer runs the web graphic and produces the frames that are composited into the programme output. Because the graphic is built with web technology, a browser engine can render the design, transparency and animation.
OGraf actions: more than an entrance and exit
Broadcast graphics need a lifecycle. A lower third may animate in, wait on air, change from one person to another, advance through several steps and finally animate out. OGraf gives the controller and graphic a shared action model.
- Play: move from the invisible state to the first on-air state.
- Next: advance to the next designed step in a multi-step graphic.
- Update: receive new data and run the designed update transition.
- Stop: play the out transition and remove the graphic from view.
Falcon Graphics places these actions on the same timeline as the animation. This makes it possible to see exactly when a data swap happens and to animate opacity, position or other properties around that moment.
Why JSON Schema matters
A graphic is only reusable when another system knows which values it can change. OGraf uses JSON Schema to describe fields and their value types. A controller can therefore generate the right controls for text, numbers, booleans, colors, choices, dates, times and other supported values.
Falcon Graphics goes further by allowing OGraf Data binding on every supported visual value, not only text. Incoming data can change position, size, rotation, opacity, visibility, typography, colors, image sources, crop values and other layer-specific properties.
For a practical walkthrough, read OGraf Data Binding: Connect JSON to Broadcast Graphics.
OGraf and CasparCG
CasparCG has long supported HTML templates through its browser-based HTML producer. OGraf builds a standardized graphics package and data model around web graphics, while many existing CasparCG workflows still expect a directly loadable HTML file.
Falcon Graphics supports both paths: export an OGraf package for compatible players, or export a self-contained HTML graphic with the callbacks required for direct CasparCG control. The design and animation work stays in the same editor.
See the step-by-step guide: How to Create CasparCG HTML Templates Without Coding.
When should you use OGraf?
- When graphics must be portable between compatible renderers and controllers.
- When operators need clearly defined, validated data fields.
- When the same template must support live updates and multi-step actions.
- When you want transparent web graphics without proprietary authoring software.
- When a production needs a format that can be inspected, versioned and automated.
Create an OGraf graphic without writing code
- Open Falcon Graphics in a modern browser.
- Start from scratch or choose one of more than 30 editable templates.
- Add text, shape, image, iframe, code, Live Data or video layers.
- Animate properties on the visual timeline and define the action ranges.
- Create OGraf Data fields and bind them to the values the controller should change.
- Preview play, next, update and stop before exporting.
- Export the OGraf package or a self-contained CasparCG HTML template.
Frequently asked questions
Is OGraf a programming language?
No. OGraf uses standard web technologies such as HTML, CSS and JavaScript. The specification adds a common package, manifest, data and action model so compatible systems know how to load and control the graphic.
Can an ordinary HTML page be an OGraf graphic?
Not automatically. An OGraf graphic must follow the specification, expose the required Web Component interface and include a valid OGraf manifest that describes the graphic, its data and its actions.
Does OGraf only work with CasparCG?
No. OGraf is designed for interoperability between compatible editors, controllers, servers and renderers. Falcon Graphics can also export a self-contained HTML template for direct use in CasparCG.
Do I need to code to create OGraf graphics?
No. Falcon Graphics provides a visual browser editor with layers, templates, a timeline, keyframes, OGraf actions and data binding.