PSD to HTML vs. Modern WordPress Development

PSD to HTML was how websites got built for most of the 2000s and 2010s. It mostly isn’t anymore – and the reasons why matter more than the history lesson. This page compares the two approaches directly, so you can tell which one actually describes what you need.

Short version: PSD to HTML converts a static Photoshop mockup into a standalone HTML/CSS template – a deliverable, not a website. Modern WordPress development takes a design (usually from Figma, not Photoshop) and builds it directly into a real, manageable, ownable website. If you already have a working site and just need a design implemented into it, you want the second one – almost always.

For most of the 2000s and into the mid-2010s, this was simply how the handoff between design and development worked. Designers worked in Photoshop because Photoshop was the standard design tool – there wasn’t a mainstream alternative built for web-specific handoff yet. A designer would flatten every button, icon, and text block onto its own layer in a PSD file, and a developer’s job was to “slice” that flat image apart: measure spacing by hand, extract individual graphic assets, and rebuild the whole thing as HTML and CSS that looked pixel-identical to the source file. It worked, and for a long time it was the only real option.

Three things, roughly in order.

Design tools stopped being image editors. Figma (and Sketch before it) design files aren’t flat images – they’re structured documents. Spacing, colors, font weights, and component states are all stored as real, readable values a developer can inspect directly, not estimate by eye from pixels. There’s very little left to “slice” in the old sense, because the file already contains the information a PSD only implied.

Design handoff got its own tooling. Figma’s Dev Mode, design tokens, and shared component libraries mean a developer can read exact spacing, hex values, and font specs directly from the design file – work that PSD-to-HTML’s manual measuring step used to exist specifically to solve.

The deliverable itself moved. A PSD-to-HTML project’s output was always a template – static files that still needed a second project to become an actual, manageable website. Increasingly, clients don’t want that intermediate deliverable at all. They want a finished, working WordPress site they can log into and update themselves, built once instead of handed off twice.

PSD to HTML gives you a template, not a website. The files you receive look correct in a browser, but nobody can add a blog post, change a headline, or update a phone number without editing code directly. For a design agency handing static templates to their own developer, this can be exactly the right deliverable. For a business that needs to run and update its own site, it’s an unfinished project, not a finished one.

Modern WordPress development gives you the finished thing. The design becomes a real WordPress theme – editable through the WordPress admin, with a proper content structure (pages, posts, and often custom post types for things like a portfolio or team directory), not a flat template someone still has to wire up to a CMS afterward.

It helps to walk through both as an actual sequence of steps, not just a table of differences.

PSD to HTML, as a project: the designer finishes a PSD and hands it off. A developer measures every element, slices out images, and writes HTML and CSS matching it pixel-for-pixel, tested across browsers. That’s the end of this project – you now have template files. A second project begins: someone (possibly a different developer entirely) has to take those static files and wire them into WordPress, Drupal, or whatever CMS the business actually runs on, rebuilding the templates as theme files, adding dynamic content areas where the static version had placeholder text, and testing the whole thing again in the CMS context.

Modern WordPress development, as a project: the designer finishes a Figma file. A developer reads spacing, color, and type specs directly from it – no manual measuring – and builds the design as WordPress theme templates from the start, with dynamic content areas built in from day one instead of retrofitted afterward. Testing happens once, in the actual environment the site will run in permanently. There is no second handoff, because there was only ever one project.

The step that disappears in the second version isn’t a shortcut – it’s a whole phase of work (and a whole set of risks: a second developer misreading the first one’s markup, content areas that don’t quite match where the design intended them, a second round of cross-browser testing) that a single-project build never has to go through in the first place.

This is the part that rarely comes up in older comparisons of the two approaches, because it didn’t used to matter: a static HTML template has no natural way to carry structured data, and it was never built with search engines – let alone AI assistants – in mind as a first-class concern.

A properly built modern WordPress site can include JSON-LD structured data (schema.org markup describing your services, FAQ content, and reviews as machine-readable data, not just visible text), a correctly configured XML sitemap, and increasingly, an llms.txt file – a young standard that helps AI assistants like ChatGPT and Claude understand and accurately cite what your site actually offers. None of this is meaningfully possible with a set of static HTML files handed off as a design deliverable; it needs to be built into the site itself, which means it needs the site to actually be a site, not a template waiting to become one.

A pure PSD-to-HTML project is often quoted as a cheaper, faster deliverable than a full WordPress build – and taken at face value, that’s true. It’s also, by itself, an incomplete project: the template still needs a second phase (CMS integration) before it’s a usable website, with its own separate cost and timeline. Comparing “PSD to HTML” against “a finished WordPress site” on price alone is comparing half a project against a whole one. The more honest comparison is PSD-to-HTML-plus-CMS-integration against a WordPress build done as one project from the start – and once you add the second phase back in, the total cost and timeline of the two approaches tend to land much closer together, with the single-project approach usually finishing faster overall since there’s no handoff gap between two separate phases.

This isn’t a case for never touching a PSD file again. A few situations where the older approach, or a piece of it, is still the right call:

• You have an in-house developer or CMS team who specifically wants a static template to integrate themselves, not a finished site.
• The deliverable genuinely is a one-off static page – a print-crossover microsite, an email template, or something intentionally outside your main CMS.
• You already have PSD files from an older project and need a small, contained update to them, not a rebuild.

None of these are “you should still avoid modern tooling” – they’re “the deliverable you actually need this time is a template, not a website,” which is a legitimate, if increasingly uncommon, thing to need.

A simple way to tell: if the honest end goal is “a working website I or my team can update,” you need modern WordPress development, even if the request started out sounding like “convert this design.” If the honest end goal is “a set of template files for someone else to integrate,” PSD-to-HTML-style front-end work – updated for Figma instead of Photoshop, but the same underlying deliverable – is still the right ask.

Can a PSD-to-HTML template just be dropped into WordPress afterward?
Not directly, no – and this is the step people underestimate most. A static HTML/CSS template has no theme structure WordPress can read: no template hierarchy, no loop pulling in posts or pages, no functions.php, none of the pieces WordPress actually needs to render dynamic content. Turning it into a working WordPress theme means rebuilding it as PHP template files, wiring up menus, widget areas, and custom fields, and testing the result as its own separate project. It’s real, billable work – not a copy-paste step – which is exactly the “second project” the comparison table above is pointing at.

Is PSD-to-HTML conversion completely obsolete in 2026?
Not completely, but it is a niche case now rather than the default path. Photoshop still exists, some agencies still hand off flat mockups instead of Figma files, and some projects genuinely just need a static template rather than a full CMS build. What’s changed is that this used to be the standard route for nearly every web project, and now it’s a specific-purpose tool for a specific-purpose job – see the “when it still makes sense” section above for the short list of situations where it’s still the right call.

How long does a WordPress build actually take compared to a PSD-to-HTML conversion?
It depends heavily on scope, but the framing matters more than the exact number. A pure PSD-to-HTML conversion for a typical marketing site might run one to two weeks. But that’s not a finished website – it’s a template that still needs CMS integration afterward, which is its own project of comparable length. A WordPress build done as one project, from a Figma file, covering the same scope, often lands in a similar total timeframe – sometimes faster, because there’s no handoff gap between two separate phases and no second round of testing in a second environment.

What happens to structured data and SEO if I go the PSD-to-HTML route anyway?
It has to be added later, by whoever does the CMS integration – it doesn’t come with the static template. That’s not necessarily a dealbreaker, but it does mean SEO and structured data become a line item in the second project rather than something built in from the start of the first one. If search visibility and AI-search readiness matter for the site (and for most business sites, they do), that’s worth factoring into which approach actually makes sense, rather than discovering the gap after the template is already built.

If you’re not sure which category your project actually falls into, that’s a five-minute conversation, not a guess. Get in touch with what you have – a Figma file, an old PSD, or just a description of what you’re trying to build – and I’ll tell you plainly which approach it actually needs, and what that looks like in practice. I’ve been doing this work, in both its old form and its current one, since 2007.