Figma to HTML
Plain HTML and CSS is the most durable thing a design can become. It has no build step to break, no dependency to update, and any developer can open the files and read them.
We write the markup by hand from your Figma file: real headings, real buttons, real lists, styled with modern CSS. JavaScript is added only where the page needs behaviour that HTML does not provide, and it is written without a library.
How a frame is read as a document
Figma has layers and groups. HTML has meaning. Translating one to the other is most of the skill.
Landmarks first
Header, nav, main and footer are marked as such, so assistive technology can jump between them.
Headings in order
A large bold line is not always a heading, and a small one sometimes is. Levels follow the outline of the content, not the font size.
Native controls
Links go somewhere and buttons do something. Accordions use details and summary, modal windows use dialog, so keyboard handling comes from the browser.
Images with purpose
Photographs get alt text and several sizes through srcset. Decorative shapes are hidden from screen readers. Icons are inline SVG that takes the text colour.
Forms that explain themselves
Every field has a visible label, the right input type and an error message tied to it.
Figma variables carried into CSS
If the file uses variables, the stylesheet uses the same names.
Custom properties
Each colour, space and radius variable becomes a custom property on the root element. Change one value and every use of it follows.
Modes become themes
A light and dark mode in Figma becomes two sets of values for the same property names, switched by the user's system setting or a toggle.
Fluid type and space
Between breakpoints, sizes scale with clamp() instead of jumping. The minimum and maximum come from the mobile and desktop frames.
Layout by grid and flexbox
Auto layout maps closely to flexbox. Page grids use CSS grid. Components that sit in both narrow and wide columns use container queries.
What makes a file quick to build
None of these are required. Each one missing adds questions.
- Auto layout on frames, so padding and gaps can be read directly
- Variables or named styles for colour, type and spacing
- A mobile frame and a desktop frame for every page
- Hover, focus, pressed and disabled states for controls
- Icons as vector layers, not flattened bitmaps
- Photographs at twice the displayed size
- The reading order where it is not obvious
- Web font files and their licence
Checks made before hand-over
Accessibility is tested by using the page, not only by running a scanner.
- Every control reached and operated by keyboard alone
- Focus outline visible on every interactive element
- Pages read through with a screen reader
- Text contrast measured; low values reported to the designer
- Layout holds when text is zoomed to double size
- Animation respects the reduced motion setting
- Markup validated
- Pages compared with the frames and differences listed
Is plain HTML the right target?
It suits
- Landing pages and campaign sites with a fixed set of pages.
- Templates that your own developers will wire into a back end.
- Documentation and brochure sites that must load fast on poor connections.
- Prototypes for user testing that need to behave like the real thing.
Choose something else when
- Non-technical staff must edit content. That calls for a CMS.
- The interface is an application with shared state across many screens.
- The same header and footer must be kept in step across hundreds of pages by hand.
Common queries about static builds
Do you use Bootstrap or Tailwind?
Not by default. If your team already works in one of them, say so and we will follow your setup.
Will the result pass an accessibility audit?
We build to the success criteria your adviser specifies and report what we tested. A formal audit and any statement of conformance come from your auditor.
How is the price worked out?
We read the file, count the distinct page types and components, and send an estimate in hours at the published rate.
Is the match with Figma exact?
Pages are compared with the frames at the agreed breakpoints and every difference is written down. Widths between those breakpoints are ours to resolve sensibly.
Tell us where the HTML is going
Send a view link and say what happens to the files afterwards: hosted as they are, or handed to a back-end team. We reply within one business day.