Framer has become one of the most popular tools for designing and publishing modern websites. Its visual editor, responsive layout system, and component-based architecture allow designers and developers to build beautiful experiences quickly.
As AI-assisted development has evolved, a new workflow has emerged: instead of manually rebuilding a design, developers want AI to inspect the design structure and generate production-ready React code.
Framer's Model Context Protocol (MCP) server is a major step in that direction. It exposes a project's internal structure, allowing AI assistants to inspect pages, components, layouts, typography, assets, and design tokens. With APIs such as getProjectXml and getNodeXml, an AI can understand a Framer project far beyond what a screenshot can provide.
However, there is still a gap between understanding a project and owning its code.
Today, exporting React components relies on Framer's official export functionality, which requires a paid subscription. While this works well, it creates a dependency on a proprietary export pipeline. At the same time, the design information required to recreate the application is already accessible through the MCP server.
This raises an interesting question:
If AI can already understand the complete structure of a Framer project, do we really need a dedicated code exporter?
The answer is increasingly no.
Large language models are now capable of transforming structured design data into clean, maintainable React applications. Instead of treating AI as a code completion tool, we can use it as a compiler that translates Framer's design tree into reusable React components.
This project explores that idea.
Our goal is not to replace Framer or reverse engineer its internal implementation. Instead, we want to build an open-source MCP plugin that extracts the information already available through Framer's public MCP interface and converts it into a developer-friendly React project.
Rather than producing opaque generated code, the plugin will focus on generating readable, modular, and customizable components that developers can easily integrate into existing React, Vite, or Next.js applications.
By making the entire workflow open source, we hope to give developers full ownership of their UI, encourage community contributions, and demonstrate how AI and open protocols can work together to bridge the gap between visual design tools and modern frontend development.
Understanding the Problem
A Framer project isn't just a collection of rectangles and text. Behind every element is a complex object containing layout information, styling, animations, constraints, interactions, assets, and references to other components.
Internally, a simple button might contain dozens of properties, including:
Position
Size
Padding
Border radius
Colors
Typography
Variants
Component references
Hover interactions
Responsive constraints
Animation settings
Many of these objects reference one another, forming a graph of interconnected data. This structure is ideal for Framer's rendering engine, but it isn't suitable for an AI model to consume directly.
The Role of an Intermediate Representation
To make a design understandable, the project must first be serialized into a structured format such as XML or JSON.
Instead of exposing internal application objects, the exporter produces a clean description of the design.
For example, a heading might become:
fontFamily="Inter"
fontSize="64"
fontWeight="700">
Build Better Products
Or in JSON:
{
"type": "Text",
"text": "Build Better Products",
"fontFamily": "Inter",
"fontSize": 64,
"fontWeight": 700
}
Both formats describe exactly the same element, but in a way that an AI model can reason about.
Why Structure Matters
AI doesn't "see" a design the way humans do. Instead, it analyzes relationships between pieces of structured information.
Consider this hierarchy:
Hero Section
├── Navigation
├── Heading
├── Description
├── CTA Button
└── Illustration
This hierarchy immediately communicates intent.
The AI understands that the button belongs inside the hero section, the navigation is a separate component, and the illustration is associated with the content rather than floating independently.
Without this structure, the AI would have to infer relationships from thousands of unrelated properties, significantly reducing accuracy.
XML vs. JSON
Both XML and JSON represent the same information but serve slightly different purposes.
XML
XML mirrors the nested structure of a design very naturally.
Hello
Get Started
Its similarities to HTML make it easy for developers to inspect and debug manually.
However, XML becomes verbose as projects grow.
JSON
JSON is more compact and integrates seamlessly with JavaScript and TypeScript.
{
"type": "Frame",
"children": [
{
"type": "Text",
"text": "Hello"
},
{
"type": "Button",
"text": "Get Started"
}
]
}
Because most frontend tooling already works with JSON, it is often the preferred choice for automated pipelines.
Why Not Generate React Immediately?
At first glance, it seems reasonable to ask AI to convert Framer directly into React.
In reality, that requires solving several difficult problems simultaneously.
The model must:
Understand the design hierarchy.
Infer layout intent.
Decide between Flexbox, Grid, or absolute positioning.
Extract reusable components.
Preserve responsiveness.
Generate clean React code.
Produce maintainable styling.
Combining all of these tasks into a single prompt often leads to inconsistent results.
A staged workflow is far more reliable.
Framer
↓
Structured XML or JSON
↓
Layout Analysis
↓
Component Extraction
↓
React Generation
↓
Optimization
Each stage focuses on one responsibility, improving both accuracy and maintainability.
Going Beyond XML
While XML and JSON are excellent interchange formats, they still describe Framer's implementation rather than the designer's intent.
A more advanced approach is to introduce a normalized Design Abstract Syntax Tree (Design AST).
Instead of exporting low-level frames and coordinates, the exporter produces semantic elements.
For example:
{
"type": "HeroSection",
"layout": "stack",
"padding": 80,
"children": [
{
"type": "Heading",
"text": "Build Better Websites"
},
{
"type": "PrimaryButton",
"text": "Get Started"
}
]
}
Notice how this representation captures meaning instead of implementation details.
Rather than telling the AI there is a rectangle positioned at specific coordinates, it communicates that this is a hero section containing a heading and a primary call-to-action button.
This semantic representation is significantly easier for AI to transform into clean React components.
The Complete AI Pipeline
A modern Framer-to-code system typically follows this architecture:
Framer Project
│
▼
Framer MCP
│
▼
Structured Export (XML/JSON)
│
▼
Design AST
│
▼
AI Layout Analysis
│
▼
React Component Tree
│
▼
Next.js + Tailwind CSS
│
▼
Production Application
This pipeline separates extraction, analysis, and code generation into distinct stages, allowing each to be optimized independently.
Conclusion
XML and JSON are not the final goal—they are the language that connects design tools with AI systems. By converting Framer's complex internal objects into structured, readable data, they provide the context AI needs to understand hierarchy, layout, styling, and component relationships.
As AI-powered development continues to evolve, the most successful tools will likely move beyond raw XML and JSON toward richer semantic representations such as Design ASTs. These representations capture the intent behind a design, enabling AI to generate cleaner, more reusable, and production-ready code.
The future of design-to-code is not about translating pixels into HTML. It is about translating design intent into software architecture.
Top comments (1)
The distinction between Framer's
getProjectXml/getNodeXmlaccess and its paid React export is the key tension here: understanding the design tree does not automatically capture the behavior developers need to maintain. I like the focus on readable, modular output for React, Vite, and Next.js instead of opaque generated code. The founder-level question is where the translation contract lives-if the generated components drift from Framer's responsive rules or interactions, ownership can become another maintenance burden rather than liberation.