Any design becomes a WordPress site.

The source is read, and how depends on which one you give it

A Figma link is read through Figma's REST API using the access you grant, which is why F2WP by HeadlineHQ has no Figma add-on to install. It requests the file and its nodes directly and gets back real layer data, so colour values, font families and weights, and spacing come out of the file rather than being inferred from a picture.

An uploaded image carries no layer data, so it has to be interpreted instead. A website URL is fetched as a live page, and F2WP asks you to confirm you own the site or have the right to convert it before it will run one.

The page is split into sections before anything is generated

F2WP counts the sections first and shows you the list. You then take the whole page from header to footer, or tick only the sections you want, with select-all and clear. Header and footer sections are tagged as such in that list.

This step exists because credits are metered per section rather than per page, so the count you approve is the cost you pay and you see it before generation starts. For an uploaded image, the picture is cropped section by section in your own browser before anything is sent.

Each section is generated on its own, by a language model, not from a template library

This is the part most tool pages leave vague, so here it is plainly. Each section is sent to a language model with instructions to return self-contained HTML and CSS, with no external libraries, no frameworks and no CDN links. There is no catalogue of pre-made blocks that your design is being matched against.

The advantage is that an unusual layout does not have to fit somebody else's template. The cost is that the output is best effort: two runs of the same section will not produce identical code, and F2WP publishes no fixed accuracy figure, because how well a design converts depends on how the source was built.

Interaction is rebuilt from the cues in the design

Where the design implies a behaviour, the generator is instructed to build it in plain JavaScript rather than flatten it into a picture. Pagination dots, left and right arrows, or a row of repeated cards that overflows the edge are read as a slider, and it is built to actually slide, with clickable arrows and dots, touch and swipe on mobile, and looping. A horizontal row of labels with one highlighted is read as tabs, switchable by click and by keyboard, showing one panel at a time. A vertical list of questions with a plus sign or a chevron is read as an accordion that opens and closes.

The honest limit is that this is cue-based. A slider screenshotted on its first slide may show no dots and no arrows at all, and there is then nothing in the image for any converter to read.

Every text and image in the markup becomes a named, editable field

Once the markup exists, F2WP walks it and turns the content into fields labelled by what they are: heading, button or link, list item, plain text. Every image tag and every CSS background image becomes an image field, seeded with the real source and surfaced in WordPress as the standard media picker, so swapping a photo is the same action as swapping any other image on your site.

The limits are fixed, and they are worth knowing before you convert a very dense section:

A colour or font control only appears where the generated CSS used the matching F2WP variable for it, so a section can arrive with fewer controls than this table suggests. One further difference worth knowing: in Gutenberg the font control is a plain text box, while in Elementor it is a real font picker.

Sections stream back while the build is still running

Sections are returned one at a time, each as it finishes, and the preview grows as they arrive rather than making you wait for the whole page. On a multi-section page you are looking at the first section rendered while the rest are still being built.

One caveat that is fair to state up front: the preview frame runs without script permission, so a slider or an accordion sits inert in the preview. The interaction only comes alive once the plugin is on your site.

The output is assembled as a WordPress plugin, not as a site

The .zip contains one folder per section, each holding that section's markup, its field definitions, its metadata and its render code, plus a single plugin file, a shared includes folder and an assets folder. Three adapters then read the same section registry: a shortcode is registered for each section, a Gutenberg block is registered for each section, and Elementor widgets are registered on Elementor's own hook.

Because the Elementor adapter loads only when Elementor is active, its absence cannot break the plugin. That is the whole reason one install works with a page builder and without one.

Installing is one click. Publishing is not

The free F2WP Connector receives the .zip, unpacks it into your plugins directory and activates it, then returns you to the WordPress plugins screen. Nothing has been published at that point. There is no page, no menu and no URL. You place each section yourself as a block, a shortcode or an Elementor widget, or set one as a site-wide header or footer.

The global header renders on the wp_body_open hook and the footer on wp_footer, which means the header depends on your theme calling wp_body_open(). On a theme that does not call it, the global header silently will not appear. On a theme that renders its own header, you will get two. A blank or canvas page template avoids both.