Flint: A visualization language for the AI era
Captured source
source ↗Flint: A visualization language for the AI era - Microsoft Research
Skip to main content
Research
Publications Code & data People Microsoft Research blog
Artificial intelligence Audio & acoustics Computer vision Graphics & multimedia Human-computer interaction Human language technologies Search & information retrieval
Data platforms and analytics Hardware & devices Programming languages & software engineering Quantum computing Security, privacy & cryptography Systems & networking
Algorithms Mathematics
Ecology & environment Economics Medical, health & genomics Social sciences Technology for emerging markets
Academic programs Events & academic conferences Microsoft Research Forum
Behind the Tech podcast Microsoft Research blog Microsoft Research Forum Microsoft Research podcast
About Microsoft Research Careers & internships People Emeritus program News & awards Microsoft Research newsletter
Africa AI for Science AI Frontiers Asia-Pacific Cambridge Health Futures India Montreal New England New York City Redmond
Applied Sciences Mixed Reality & AI - Cambridge Mixed Reality & AI - Zurich
Register: Research Forum
Microsoft Security Azure Dynamics 365 Microsoft 365 Microsoft Teams Windows 365
Microsoft AI Azure Space Mixed reality Microsoft HoloLens Microsoft Viva Quantum computing Sustainability
Education Automotive Financial services Government Healthcare Manufacturing Retail
Find a partner Become a partner Partner Network Microsoft Marketplace Software companies
Blog Microsoft Advertising Developer Center Documentation Events Licensing Microsoft Learn Microsoft Research
View Sitemap
Return to Blog Home Microsoft Research Blog
At a glance
Polished charts from simple specs . Flint allows AI agents to reliably generate expressive, visually polished charts from simple, human-editable specifications.
Semantic types guide design . Flint leverages semantic data types to express meanings of data. They help the compiler choose appropriate scales, baselines, formatting, and color schemes.
Layouts adapt to the data . Flint automatically manages sizing, spacing, labels, and layout so charts remain readable as cardinality and density change, without explicit user configurations.
One spec can target multiple backends . A single Flint specification can compile to Vega-Lite, Apache ECharts, or Chart.js without rewriting the chart from scratch.
Built for agent workflows . The open-source project includes the flint-chart library and the flint-chart-mcp server , so agents can create, validate, and render charts directly in chat or coding environments.
Figure 1. Flint supports a diverse collection of visualizations with its simple spec, which can be rendered with visualization libraries like Vega-Lite, Echarts, and Chart.js.
Creating a good chart requires many design decisions: how dates should be parsed, whether a scale should start at zero, how values should be formatted, how much room labels need, and which colors make the data easier to read. Modern visualization libraries such as Vega-Lite, Apache ECharts, and Chart.js expose these controls, but there is a trade-off: Short specifications that rely on system defaults often produce uninspiring charts, while polished visualizations require detailed specifications with purposely chosen parameters that are often verbose, fragile, and error-prone.
This trade-off becomes sharper as large language models (LLMs) and AI agents take on more visualization work. Agents are especially prone to errors when they must manage complex, low-level specification details, and the resulting fragile code can be difficult for people to inspect, repair, or reuse. Ideally, we need something in between: a compact specification that agents can produce reliably, people can edit directly, and a system can compile into a well-designed chart.
To address this challenge, we introduce Flint (opens in new tab) , a visualization intermediate language for AI-driven chart creation. Flint helps AI agents create expressive, attractive charts from simple, human-editable chart specs. Instead of requiring verbose low-level parameters for scales, axes, spacing, and layout, the Flint compiler derives optimized chart settings from the data, semantic types, chart type, and encodings. The same Flint spec can render through multiple backends, including Vega-Lite, Apache ECharts, and Chart.js.
Figure 2. Flint compiles a compact, human-editable chart specification into a complete backend-native specification and rendered visualization. In this heatmap example, the Flint spec names semantic types (period as YearMonth, newUsers as Profit) and maps fields to visual channels. The compiler derives the Vega-Lite details, including temporal parsing, axis formatting, color scale, cell sizing, legend configuration, and layout.
How Flint works
Figure 2 illustrates the how the Flint compiler turns a compact chart specification into a refined heatmap.
To produce a high-quality heatmap, traditionally, we need to explicitly tell the system with low-level chart properties about how to process the period field, how to properly label MonthYear values, size individual heatmap cells, and choose a color scale that appropriately represents positive and negative newUsers values. Without these configurations, visualization libraries must guess from field names and raw values, which can lead to charts that are technically valid but potentially misleading. While they are important, hard-coding these details can be difficult and error-prone, and they make specification fragile and hard for users to understand or adapt.
In Flint, these low-level details are systematically managed, where the compiler infers them from high-level data and chart specifications. Here, the data specification captures semantic types and optional metadata, and the chart specification defines the chart type and maps fields to visual channels such as x, y, color, size, or facet. From this information, the compiler derives the parsing rules, scales, axes, aggregations, formatting, color schemes, layout, and generates the backend-native specification, which is used to render the final polished visualization. This frees users from explicitly setting fragile and error-prone low-level details.
Furthermore, because the intermediate representation is separate from any single rendering library, Flint can target backends with very different APIs and programming models. Users can keep the same compact chart intent while...
Excerpt shown — open the source for the full document.