Figma Components From Import: Turning a UnHTML Pro Page Into Reusable Styles
Most of an UnHTML Pro import already has auto layout, text styles, and components. Here is how to finish organizing what Pro leaves as plain frames.
What Pro already converts on import
Getting figma components from import isn't a manual chore anymore, not for most of a page anyway. When you run a Pro import, the plugin reads the page's own CSS and maps spacing, padding, wrap, and stretch behavior into auto layout: gap for the distance between objects, padding for the space around them, and a direction setting for vertical, horizontal, or grid flow. Sections whose geometry cannot be reproduced with auto layout fall back to absolute positioning on their own, so a frame that cannot be represented cleanly does not come through broken.
The same pass also handles two things designers usually do by hand. Repeated type, headings, body copy, captions, becomes shared text styles, so editing one style updates every layer using it. And repeated visual elements, cards, nav items, testimonial blocks, become real components with instances and variants, following the same main component and instance model Figma uses natively: the main component holds the source of truth, and instances are linked copies that inherit its updates.
Pro is deliberately conservative about the second part. If replacing a repeated occurrence with an instance would shift its position or alter the layout it captured from the page, Pro leaves it as a plain frame instead of forcing a component that would drift from the original. That's the gap this article covers: finding what got left as a plain frame, and finishing the job by hand.
If you haven't run the import yet, see importing a React or Vue site into Figma for the capture step that comes before any of this.
It helps to think of the import as two passes rather than one. Pro handles the first pass on its own: it reads geometry, looking at how every frame on the page was laid out in CSS, and reproduces that with gap, padding, and a direction setting that mirror flexbox and grid behavior. The second pass, the one this article covers, is about naming and reuse: turning geometry that already works into styles and components a team can actually maintain. Skip it, and you get a file that looks right on the day of import and gets harder to edit every day after.
Step 1: Audit the import report for what's left as plain frames
Every Pro import ships an import report alongside the file. It lists every font substitution (a missing font swapped for Inter by default, logged so nothing changes silently) and flags which repeated sections were converted to components versus kept as plain frames.
Open the report first, before touching the canvas. Cross-reference the flagged sections against the page's visual repeats: card grids, pricing tiers, testimonial rows, footer link columns. These are the places most likely to have been left as frames on purpose, and they're also where a manual pass pays off fastest, since fixing one card template updates every card once it becomes an instance.
Don't assume a section was skipped by mistake. The report exists precisely so you can tell the difference between "Pro couldn't reproduce this layout" and "Pro didn't attempt this because a component would have moved it."
Two lists are worth writing down before you touch the canvas: sections flagged as absolute-position fallbacks, and sections flagged as plain frames despite repeating. The first is a layout problem, a section whose original CSS couldn't map cleanly to auto layout, and fixing it may mean rebuilding that one frame's structure by hand. The second is a naming and componentization problem: sections that are already laid out correctly and just need to become real components. Steps 2 through 4 are about that second list. Treat the first list as a separate, smaller pass, since forcing auto layout onto a frame that genuinely can't support it produces the same kind of drift Pro was trying to avoid in the first place.
Step 2: Turn any remaining repeated type into text styles
For type that Pro didn't already convert, usually one-off headings or type that didn't repeat often enough to be flagged, you can apply the same treatment by hand. Select a text layer, open the type section in the right sidebar, and create a new style. Name it by role and size (Heading/Large, Body/Default, Caption/Small) rather than by its position on the page. The name is what your team will see when they pick a style six months from now, not the page it came from.
If a layer should keep its current appearance without being tied to a shared style, detaching removes the link to the style definition but keeps the layer's current property values intact. That matters when cleaning up an import selectively: apply a style to test it, then detach the one layer that needs to stay slightly different without touching the rest.
Creating and editing styles requires can-edit access on a paid Figma plan tier (Education, Professional, Organization, or Enterprise). Viewers can apply an existing shared-library style but can't create a new one, worth knowing before you hand the file to someone for review.
Step 3: Componentize the sections Pro intentionally skipped
This is the step that turns the plain frames flagged in your audit into real components. Select the layers that make up one repeated section and choose Create component; Figma nests the selection inside a component frame, marked with the purple component icon in the layers panel. When several separate sections need the same treatment, three pricing tiers, five testimonial cards, selecting all of them and choosing Create multiple components turns each one into its own component in a single pass, rather than repeating the single-selection flow section by section.
Keep Pro's caution in mind as you go. If turning a specific occurrence into an instance would shift its position, either resize the frame so the instance fits cleanly, or leave that one occurrence as a frame and componentize the rest. A component that has to be nudged back into place after every use is worse than a frame that just stays a frame.
Once a section is a real component, the main component becomes the place you make every future edit: change the padding, swap an icon, adjust the copy pattern, and every instance across the file picks it up.
Watch for one edge case that shows up a lot in imported pages: sections that look identical but were built from slightly different underlying markup, a card component with an optional badge, say, versus one without. Forcing both into a single component with no variant support means the badge either shows on every instance or none of them. Component variants solve exactly this. Build the base component once, then add a variant property (Badge: Yes/No) so each instance can differ in a defined way without breaking the link back to the main component. It's one extra step at creation time, and it saves a rebuild later when the page adds a third variation you didn't plan for.
Step 4: Organize for handoff
Before publishing anything to a team library, group the new text styles and components you just created and give them a naming convention that matches whatever Pro auto-generated, so the file reads as one system rather than two. A componentized, styled file gives a team a faster editing loop than a raw import: one place to update a repeated section, one place to update a type role, a layers panel that shows structure instead of a flat stack of absolute-positioned frames.
This is also the point to decide what stays local to the file and what moves to a shared library, since library access follows the same can-edit rule as creating styles and components in the first place. If your team already has a components library for other work, this is usually the moment to fold the new ones in, rather than letting the import stay its own island.
The UnHTML Pro conversion pass gets most of a page to this point automatically. What's left, mostly a handful of sections the import deliberately kept conservative, is a short, mechanical pass rather than a redesign.
Conclusion
A Pro import already hands you auto layout, text styles, and components for most of a page. The CSS-to-auto-layout mapping and the componentization pass both run automatically, and the import report tells you exactly where they stopped. Auditing that report, finishing the text styles on any leftover type, and componentizing the sections Pro intentionally left as frames is what turns the file from a faithful capture into something your team can actually work in. Repeat the same short pass any time you re-import a page that has changed.
Questions
- Does UnHTML Pro componentize everything automatically, or is manual cleanup still needed?
- Pro converts repeated type into shared text styles and repeated elements into real components with instances and variants during import, but it deliberately leaves some repeats as plain frames when replacing them with an instance would shift position or break the captured layout. Those sections need to be componentized by hand afterward.
- Why did some repeated sections stay as plain frames instead of becoming components?
- Pro is conservative about drift. If turning a repeated element into an instance would move it or alter the layout it captured from the page, Pro keeps it as a plain frame instead, so the import does not quietly diverge from the source page. Reviewing the import report shows which sections were left this way.
- What is the difference between a Figma text style and a component?
- A text style bundles font, size, line height, and related type properties under one reusable name, and editing the style updates every layer using it. A component bundles layers, icons, buttons, whole sections, with a main component acting as the source of truth and instances as linked copies. Text styles are for type properties, components are for reusable groups of layers.
- Do I need a paid Figma plan to create text styles and components from an import?
- Creating and editing styles and components requires can-edit access on a paid Figma plan tier: Education, Professional, Organization, or Enterprise. Viewers can apply existing shared-library styles and drop in component instances, but cannot create new ones.