Grazy

Active Development

From live HTML to editable Figma layers

Bridge the gap between code and design. Capture live HTML and convert it into editable Figma layers, then export starter code for multiple platforms.

How It Works

Import HTML to Figma

Capture live websites, selected HTML elements, and screenshots, then import the result into Figma as editable layers

Export to Code

Export your Figma designs to starter code in multiple frameworks

Inside the plugin

The core workflow lives in the plugin: import live HTML, inspect the result, export code, and move between design tokens and assets.

Grazy plugin interface screen 01 — Plugin screen 01

Grazy plugin interface screen 02 — Plugin screen 02

Grazy plugin interface screen 03 — Plugin screen 03

Grazy plugin interface screen 04 — Plugin screen 04

Grazy plugin interface screen 05 — Plugin screen 05

Grazy plugin interface screen 06 — Plugin screen 06

Architecture overview

What looks like a simple bridge between HTML and Figma is actually a multi-stage translation system. Each step preserves a different kind of intent so the result can stay editable, exportable, and useful across design and development workflows.

Browser capture

The extension inspects live pages, captures selected elements or screenshots, and resolves layout, styles, images, SVGs, pseudo-elements, CSS variables, and framework utility classes.

Normalized payload

Captured UI is translated into a Figma-oriented JSON structure with sizing, spacing, typography, fills, gradients, shadows, and metadata preserved for import.

Figma reconstruction

The plugin rebuilds the interface as editable Figma nodes, including auto-layout frames, text, images, vectors, list structures, and fallback font handling.

Selection serializer

Designs can then move back out of Figma through a shared intermediate model that extracts layout, styling, typography, SVG identity, component metadata, and tokens.

Export adapters

Platform adapters generate code for web and native targets, with specialized logic for stacking, fonts, SVGs, tokens, component structure, and full-page sections.

Product layer

AI enhancement, queued exports, analytics, benchmark tracking, and build profiles support the core engine. The public plugin no longer requires a subscription or sign-in.

Engineering challenges

Most of the hard work sits in the translation details: deciding what a live UI element means, recreating it as design structure, then exporting it back into code without losing too much intent.

Capturing the messy web

Live interfaces rarely map cleanly to design layers. Grazy has to infer intent from computed styles, utility classes, inherited values, hidden elements, gradients, SVGs, images, and responsive layout behavior.

Rebuilding editable Figma layers

The import path is not a screenshot-to-canvas shortcut. It reconstructs editable nodes, auto-layout relationships, typography, fills, spacing, and image data so the output can still be designed with.

Maintaining export fidelity

The export pipeline has to preserve Figma semantics that code does not express directly, such as text auto-resize modes, stack order, nested component intent, SVG identity, and token naming.

Keeping the product shippable

The plugin grew into multiple build profiles, feature flags, tests, and AI provider paths while still needing to fit inside the constraints of a Figma plugin runtime. Removing the old licensing and sign-in flows also reduced its payload.

Translation engine

The most time-consuming part was building the code generation pipeline. It had to recognize component structure, preserve design semantics, and emit useful code for very different UI platforms.

Component detection and export required separating visual structure from reusable component intent.
The shared intermediate node model keeps platform adapters from each inventing their own interpretation of a Figma selection.
Web exports account for stacking, font embedding, SVG normalization, token names, responsive sections, and full-page segmentation.
Native-style adapters translate the same source model into different layout systems rather than only changing syntax.
AI enhancement is layered on top of deterministic code generation, so the baseline export remains usable even when AI is disabled.

Supported output families

HTML/CSSReactVueSvelteFlutterSwiftUIJetpack ComposeReact Native

Not every target has the same maturity level, but each one pushed the system to separate reusable design intent from framework-specific syntax.

Making Grazy free

Grazy started with plans for subscriptions and licensing. In July 2026, I chose to remove paid gating and simplify access to the plugin. That decision also meant removing code that the product no longer needed.

Version 33 removed paid gating in July 2026. Grazy became available without subscriptions or sign-in.
Version 34 removed the old sign-in, licensing, and gating code to reduce the plugin payload, alongside fixes for blur conversion and text line height.
The plugin includes a local MCP bridge for connecting external tools to its Figma workflow.
The focus is on editable imports and useful starter code, with conversion fidelity varying by export target.

Key Features

Export to code: HTML/CSS, React, Vue, Svelte, Flutter, SwiftUI, Jetpack Compose
Design system sync between code and Figma
AI workflow bridge: ChatGPT/v0 to Figma
QA & design review with overlay comparison
Browser capture for DOM elements, screenshots, and UI analysis
Living documentation from production UIs

Technology Stack

Browser ExtensionFigma PluginChromeFirefoxTypeScriptReactViteConvex

The story of Grazy

Grazy was born out of a personal frustration I experienced while working as a designer. I lacked the proper tools that would allow me to quickly test and iterate designs based on live HTML elements. Additionally, there were so many times I needed to reproduce live design elements without access to older sources, because the code was in production, but legacy.

At first, it started off as a simple way to play around with Claude Code. I wanted to see how viable it would be to build a tool that imports live HTML into Figma. Armed with a decent understanding of HTML and of Figma autolayout constraints, I started to put something together.

It was the Christmas holidays, 2025, and I had some time to myself, so I started fleshing out the core functionality: a browser extension and the Figma plugin that would be the backbone of Grazy. It took me a couple of days to get it into a working state.

The next week I started to think: what if I could also export code? I was working on my portfolio in parallel and thought how useful it would be to design bits in Figma and export the code to refine them. So I began working and got it to a decent state in a couple of days.

I played around with it and built support for more UI frameworks to see how viable it could be. Then it clicked: this is the type of product that bridges the gap between designers and developers. It can save developers time and enable designers to try coding themselves. At the very least, it helps people better understand how HTML works.

When it started, the UI was entirely hacked together using Claude Code. Lately I have used Grazy itself to extract HTML from its own interface, import it into Figma, and use it in my marketing materials.

Discovered use cases

Here are some of my favorite uses-cases I have discovered for Grazy so far while working with it:

I also dogfooded it at work on a project where the live product was the only reliable source of truth. The import workflow helped me recreate UI where the original Figma sources no longer existed, and later helped turn a live product surface into the starting point for a design system.

Used the import functionality at work to recreate production UI when the original Figma sources were missing.
Used live product capture as the foundation for building a design system from an existing product.
Used Grazy code generation to build parts of the Grazy landing page and Omvra pages.
Export color and size tokens from the design system straight to production.
Using Grazy to extract live UI for marketing materials. This is by far my favorite use-case so far.
Using it to study how developers built interface elements I loved using.
Quick prototyping. I exported figma components straight to code to create a quick HTML prototype for a new feature at work.
By adding inline base64 image embedding, I also made it super viable as a tool for creating HTML newsletters and emails.
Used it to reverse-engineer some older newsletters at work.
Used it to extract some legacy HTML at work to refactor and bring up to date.

Workflow examples

Competitive analysis - Capture demo

Capturing and importing a pricing box from a live website.

Email Newsletter - Capture demo

Importing the design of a live email newsletter into Figma.

Marketing and concept visuals

These illustrations helped explain Grazy’s two-way workflow before the product screenshots were available: bring live interfaces into Figma, then turn editable design decisions back into code.

Illustration showing Grazy export code and design tokens — Exporting editable Figma work into starter code across multiple platforms.

Illustration showing Grazy’s import and export workflow — Positioning Grazy as the bridge between live HTML, Figma structure, and production code.

Launching Grazy

After polishing it up a bit, I decided to launch it so others might betatest it and get some feedback. That's when it hit me that I could really have a decent product on my hands, with perspective users in both the design and development communities.

So I spun up a landing page, added some content, and launched it. I have been chipping away daily ever since, incrementally making it better and adding new features that could make it better.

Lessons learned

AI can be incredibly helpful in cutting down time from idea to prototype and production. But you need to have a very solid understanding of architecture, design patterns and principles to be able to efficiently guide it and get the most out of it.
A single person can still launch a full product that solves real problems for real users. But it will take much more time than it would for a team. Yet if you can efficiently leverage tools like Github Copilot and Claude Code, you can shorten that time.
Building the product and adding features is only half the battle. Marketing, community building and user engagmenet is the really difficult part of helping you lift it off the ground.
Starting off a product free, will be a good way to make it difficult to later monetize it. Consider starting with a paid plan from the get go, even if it's a small amount. That also validates the need.
Don't rely on friends to help you with feedback, help or opinions. They will either hype you or simply not care. Seek out real users as fast as you can.
Building anything that does not have AI inside will effectively put a brake on your products growth during this time, and make it considerabley less attractive for users. Even if your design is solid and built for efficiency and privacy. It's a much much tougher sell.

Some fun facts

v34

published on July 27, 2026, with export fixes and a smaller plugin payload

implemented export adapters, including separate React Tailwind and CSS outputs

Free

paid gating removed in July 2026; no subscription or sign-in required

2 ways

live HTML into editable Figma layers, and Figma designs back into starter code

MCP

a local bridge connects external tools to the plugin’s Figma workflow

1 model

a shared intermediate representation feeds the platform-specific export adapters

Biggest challenge faced

Building the translation engine that converts Figma structures into useful code. By far the most time-consuming part was improving component detection and export accuracy while testing against different samples, each with a different design and implementation approach.

Code

Although the code was executed using Claude code, and Github Copilot, architecture, translation and design patterns were all entirely done by me, same as the UI design and the initial concept, planning and feasibility study.

What's next for Grazy?

With subscriptions and licensing removed, the direction is simpler: improve the conversion engine and make the existing workflows more dependable.

Areas for further refinement include:

Deepening accessibility-aware code generation, especially semantic roles, states, labels, and platform-specific accessibility APIs.
Improving conversion fidelity across all adapters with stronger regression coverage for typography, stacking, SVGs, assets, and component structure.
Hardening newer framework exports, including Angular, Blazor, MudBlazor, Svelte, Vue, and React Native.
Expanding bundled exports into more portable project packages, especially external raster/SVG assets and multi-file component downloads.
Refining component detection so exports can move from visual code toward reusable starter components.

I loved working and building this suite of products, mostly because it gives me a break from the usual design work while giving me the freedom to experiment, learn and explore new technologies and workflows. Plus I can always do real-world testing of my own theories related to product.