50kg/image-to-slice: Turning AI-Generated UI Screenshots into Figma Layers and HTML

What 50kg/image-to-slice actually solves, and who it is for

The README opens with a complaint that will be familiar to anyone who has tried to hand a generated UI mockup to a coding model: the picture looks good, but the code reconstruction does not. The stated reason is that a flat image mixes elements that can be expressed natively in code with elements that can only survive as static cutouts, and a model reading the whole image cannot reliably tell them apart.

The project's own framing of the market is worth quoting because it draws the boundary it cares about. It separates "AI layering" tools, which serve posters and e-commerce graphics and usually export PSD or layered assets, from "AI matting" tools, which remove a background to leave one subject. Neither answers the question this project poses: how should this UI be built? Its answer is what it calls AI cutout (AI切图), a pipeline that decides which parts of an App, web or software interface become code or native Figma nodes and which stay as image assets.

The intended user is therefore narrow. You are a designer or front-end engineer starting from a generated or captured UI screenshot, and you need a structured handoff rather than a bitmap. If you are splitting a photo into a grid for Instagram, nothing in this README is addressed to you, and the related search vocabulary around free online image splitters will lead you to the wrong tool.

The decomposition pipeline: from flat UI image to confirmed assets

The README walks through one case end to end, and the flow is linear: a flat UI image goes through AI decomposition or manual box selection, produces automatically selected cutout assets plus a recommended background completion, then you confirm the occluded regions and let AI inpaint them, then you either import cutouts into Figma or download HTML.

Input can come from three places. You can generate an image with a text prompt, generate from one or more reference images, or load an existing PNG, JPEG or WebP screenshot. The README states that text-to-image, image-to-image and image understanding sizes generally need to fall in the 256 to 4096 pixel range.

The AI decomposition step returns three categories of judgement: cutout assets that can be cropped directly, background candidates that should stay as one complete image, and a code layer better expressed as HTML/CSS or Figma native nodes. The README is explicit that this is not the final answer and that manual box selection, moving, scaling, corner radius adjustment, hiding, deletion and replacement are all available afterwards.

The background confirmation window is the part worth understanding before you use it. A blue box marks the extent of a complete background candidate. A red dashed box marks interface elements sitting on top of that background, which need to be removed as repair regions and reconstructed from context. The README is careful about what the red box is: not an exported cutout, but a removal mask handed to the inpainting model. Its guidance is that buttons, navigation, form controls and interface text usually should be removed, while artistic text, illustrations, scenes, products and brand content blended into the picture usually should be kept.

Background inpainting keeps two versions, and does not choose for you

After confirming the red regions, the generate complete background action sends the confirmed blue background extent and red removal regions to an image editing model. The design intent is that a background occluded by buttons, text or cards gets reconstructed, so that later the complete image can sit underneath and foreground elements can be layered on top.

The detail that distinguishes this from a one-click inpaint is that two complete versions are kept side by side and neither overwrites the original asset. The first is the model's direct return, described in the README as usually more visually coherent overall but potentially altering regions you did not select. The second composites only the repaired regions back into the original image, leaving unselected areas at their original pixels. The stated reason for keeping both is that the user compares and picks one, rather than the plugin deciding automatically. You delete the one you do not want.

There is a second, more local inpainting path. Inside the cutout editor, a brush marks missing regions, an eraser removes mask mistakes, a thickness control adjusts either tool, and AI repair sends the mask, the current cutout and the original image context to the inpainting model. Saving writes the previewed result back to the cutout asset.

A separate preview feature deserves a note because it is not AI at all. The preview completion control generates a local gradient fill based on the top, bottom, left and right edge colors around each cutout box. It exists to check whether the background revealed by a selection looks natural, and the README's advice when it does not is to adjust position, size or reselect rather than to call a model.

Installing and a first run: Node, build, and the two output paths

The repository is a private npm package (version 1.1.2) with a Node engines constraint of 20.19.0 or higher, so check that before anything else. The scripts block names the API server, the three-part build, and the test command. The build is split into UI HTML generation, the plugin main bundle, and a Figma simulator bundle.

npm install
npm run build
npm test

npm run build runs build:ui, build:plugin-main and build:figma-sim in sequence. npm test runs the unit tests, then syntax-checks server.js, dist/code.js, dist/figma-sim.js, src/plugin/main.js and both Vite configs.

The API server that the high-fidelity capture path depends on is started separately by the api script, which runs node server.js.

npm run api

For a local look at built output without the plugin host, the preview script serves the current directory on port 4173 bound to loopback.

npm run preview

There are also one-click environment scripts at the repository root, 一键部署环境.bat for Windows and 一键部署环境.command for macOS. The README does not describe what they install, so read them before running.

The first real use is the four-step flow. Load a local PNG, JPEG or WebP, or generate one. Click AI decomposition. Confirm the blue background extent and red removal regions. Then choose an output. The cutout import path places the complete background and cutout assets at their original coordinates into a new Figma frame in the plugin, and in the standalone web mode the same button reads download cutouts .fig for manual import. The README notes this path does not request AI.

The AI layer import path is the one that costs a model call. It analyzes text, layout, component nesting and cutout references, and produces an HTML/CSS preview. Cutout image data is not resent as a reference image; it is injected into the HTML by trusted asset ID. The README states the first run requests the model, later runs reuse a successful cache, and only clicking re-run AI recognition refreshes the structure.

The two Figma capture paths, and why the default is the constrained one

Exporting to Figma has a fork that determines how much of your design stays editable. The default path uses ordinary DOM capture to convert the current HTML preview into Figma layers. In the plugin it writes straight to the canvas; on the web it downloads a .fig file for manual import. The README describes it as suited to regular text, images, solid colors, corner radius, shadows and basic layout, and notes it is faster and does not depend on server-side Chromium.

The optional path is high-fidelity capture via Playwright/CDP, enabled by a checkbox in import settings. It starts Playwright Chromium through the local API service and reads paint information over CDP. Visual layers that are hard to reproduce as editable objects are supplemented as transparent PNGs, while text and basic structure that can be converted reliably are kept. The README's own trade-off table says the result is usually closer to the browser preview but cannot guarantee everything stays editable, and the first use requires installing the browser.

npx playwright install chromium

This is the honest constraint of the project. If your preview leans on pseudo-elements, filters, clipping, complex backgrounds, blend effects or some complex gradients, the default capture will not represent them faithfully, and the fallback buys fidelity by converting some layers to images. You are trading editability for appearance, and the README does not claim otherwise.

There is a third, independent export that has nothing to do with AI layers. Select any complete Figma frame and click export HTML, and the plugin exports a fixed-size HTML ZIP. The README states this frame does not have to have been produced by the plugin.

What you get in the HTML ZIP, and what the asset list controls

Clicking download HTML in the AI layer import preview produces a ZIP containing index.html, styles.css, script.js and an assets directory. Unzip it and open index.html directly in a browser to inspect the generated DOM, styles and image resources in developer tools. That is the whole contract: a static bundle, not a framework project, with no build step described.

The asset area is where manual correction actually happens, and it is more developed than the AI step. Export cutout package bundles the currently exportable cutouts, original coordinates and asset information. A batch transparent action applies ordinary transparency handling. Batch hide and show exist for a specific practical reason: when selection boxes overlap, hiding irrelevant ones prevents occlusion so you can keep selecting and adjusting coordinates. Copy and paste duplicate selected assets with Ctrl/Cmd + C and Ctrl/Cmd + V. Delete removes one or more selections, but the README notes an asset cannot be deleted while AI is processing it. Assets support Ctrl/Cmd multi-select, drag reordering and show/hide, and the README is clear that reordering only affects list order, not original image coordinates.

That last sentence matters more than it looks. The list is a view, not the source of truth for placement, so reorganizing your assets will not move anything on the canvas.

Where this is the wrong tool, and what to compare against

The failure mode is scope. The README defines the project against generic image splitting and background removal, and that definition cuts both ways. If your goal is to cut one picture into six equal pieces, or to produce a grid for a social post, the AI decomposition step will still try to classify your content as code-able layers and image assets, and you will spend more time overriding it than cropping. The related search terms around free online splitters, splitting an image in two, or Canva describe a different job.

The closest alternative in kind is a generic AI layering tool of the poster and e-commerce type that exports PSD or layered assets. The difference in approach is the classification decision. A generic layering tool asks how this poster should be re-edited, so an artistic headline becomes an editable layer. This project asks how this UI should be built, so the same artistic headline would be kept as an image asset to preserve its visual effect, while a plain button becomes code. If your deliverable is a PSD for a designer, the generic tool matches; if your deliverable is a Figma frame or HTML, this one does.

A second alternative is not to decompose at all and hand the screenshot straight to a coding model, which is the situation the README describes as producing poor output. That comparison is the project's own premise rather than a measured result, so treat it as a stated motivation.

The other real limitation is the model dependency. Sizes are constrained to 256 to 4096 pixels, the README notes vendors may support only some of the offered aspect ratios, and the AI layer import path requires a model request on first run. Nothing in the README describes an offline mode for the decomposition or inpainting steps.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-15, the same day as the v1.1.2 release. The preceding releases, v1.1.1 and v1.1.0, landed on 2026-08-13 and 2026-08-12, so the recent release cadence is compressed into a few days rather than spread out, and the README does not describe a support policy or a deprecation process.

The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the extent of what the repository states; it says nothing about the licensing or terms of the image generation, image understanding and inpainting models the plugin calls, and those are separate services with their own terms. If you plan to ship generated assets, that distinction is the one to check, and it is not a question the MIT file answers.

Upgrade cost is mostly environmental. The package pins playwright at 1.62.1 as a dev dependency and requires Node 20.19.0 or higher, so a Node downgrade breaks the build. The high-fidelity capture path additionally needs a Chromium download per machine, and the local API server has to be running for that path. The dependency list is short and includes sharp, makerjs, svgpath, fast-xml-parser, openfig-core, zstd-codec and @neplex/vectorizer, several of which are native or binary-adjacent, so install friction on unusual platforms is plausible even though the README does not discuss it.

Editorial conclusion

Adopt it if your input is a generated App, web or software UI image and your output is either an editable Figma frame or an HTML/CSS ZIP, because that is the only pipeline the README describes. Do not adopt it if you want a generic image splitter for Instagram grids or poster layers; the project states its scope is UI development, and its asset classification is explicitly a suggestion you are expected to override. Before committing, verify two things yourself: that your Node version satisfies the engines field, and that the default DOM capture path handles your preview, since the README only offers the optional high-fidelity capture as a fallback for pseudo-elements, filters, clipping, complex backgrounds, blend effects and some complex gradients, and it states it cannot guarantee everything stays editable.

Frequently asked questions

Official sources

1. 50kg/image-to-slice on GitHub
2. Issues
3. License: MIT
4. README
5. Releases