The Ultimate PSD-to-HTML Tutorial Collection: From Photoshop Design to Responsive Websites

ThatPainter is reader-supported. When you buy through links on our site, we may earn an affiliate commission. Learn More

PSD-to-HTML conversion is not a one-click file conversion. It is the process of interpreting a Photoshop design, exporting only the assets a website genuinely needs, and rebuilding the design as semantic HTML, maintainable CSS, and—where required—JavaScript. The best modern workflow preserves the visual hierarchy of the PSD without turning the page into a collection of screenshots, slices, or absolutely positioned images.

This collection takes you from PSD inspection and asset export to responsive layout, accessibility, performance testing, framework choices, and troubleshooting. It also explains when manual coding is the right answer—and when Figma, Webflow, Bootstrap, Tailwind, automation, or a professional service may be more appropriate.

What “PSD to HTML” means today

A PSD contains visual information: layers, typography, colors, effects, images, and approximate layout relationships. It usually does not contain the complete specification for a website. It cannot reliably tell you the correct semantic elements, keyboard behavior, URL destinations, form validation, responsive behavior between supplied artboards, or how dynamic content should behave.

For a production site, PSD-to-HTML means design-to-code implementation:

1. Inspect the Photoshop document.
2. Identify page regions, content, decoration, and reusable components.
3. Export photographs, logos, illustrations, and other genuine assets.
4. Recreate the structure with semantic HTML.
5. Reproduce typography, spacing, colors, borders, shadows, and layout with CSS.
6. Add responsive behavior, interaction, and accessible states.
7. Test the result visually and functionally across browsers, devices, input methods, and content conditions.

Exporting the entire PSD as an image, or slicing every layer into separate images, is not a functioning website. It produces a visual artifact with poor accessibility, weak responsiveness, limited search visibility, and difficult maintenance.

Also separate this workflow from PSD-to-email conversion. Email markup has different constraints and often relies on table-based layouts for client compatibility. A normal website should not be built using those legacy email techniques.

Choose the right conversion approach

Approach	Best for	Main strengths	Main risks
Manual HTML and CSS	Production sites and custom interfaces	Maximum control over semantics, accessibility, performance, and maintainability	Requires more front-end skill and implementation time
Bootstrap	Teams wanting established responsive utilities and components	Fast setup, familiar conventions, predefined responsive patterns	Default styles may require extensive overrides and can look generic
Tailwind CSS	Custom interfaces using utility-based styling	Fine-grained responsive control and useful design-token integration	Class-heavy markup and a required project setup
Figma as an intermediate workflow	Teams moving from Photoshop to collaborative design handoff	Auto layout, components, design systems, and more explicit responsive relationships	PSD migration may require manual reconstruction and cleanup
Webflow or another visual builder	Marketing sites, landing pages, and content sites	Fast visual iteration and publishing workflow	Platform constraints, imperfect imported semantics, and possible lock-in
Automated converter	Prototypes, scaffolding, and simple pages	Can provide a starting point quickly	Generated markup may be fragile, inaccessible, or difficult to maintain
Professional service	Teams without implementation capacity	Outsourced execution and potentially faster delivery	Quality varies; ownership, accessibility, testing, and maintenance must be defined

Bootstrap describes a component-oriented framework, while Tailwind emphasizes utility-level control. Neither is automatically better; choose according to your team, codebase, visual system, and maintenance expectations. Figma’s responsive design overview also discusses these differing approaches.

Prerequisites

Minimum front-end knowledge

• Basic HTML document structure and semantic elements.
• CSS selectors, inheritance, specificity, and the box model.
• Flexbox and CSS Grid.
• Media queries, responsive units, and fluid sizing.
• Basic JavaScript if the design includes menus, tabs, sliders, modals, or other stateful interactions.
• Browser developer tools and a code editor.
• Image formats, compression, and basic web performance concepts.

What a usable PSD should contain

• Named layers and logically grouped sections.
• Separate text layers instead of text baked into images.
• Separate logo, icon, photograph, and illustration assets.
• Font names, weights, and licensing information.
• Consistent alignment and spacing.
• Desktop and mobile variants where possible.
• Hover, focus, active, disabled, loading, error, and empty states.
• Notes describing interactions and responsive behavior.

A single desktop PSD is not a complete responsive specification. If the file does not show mobile behavior, intermediate widths, navigation collapse, or content overflow rules, those decisions must be documented with the designer or product owner rather than silently hidden in CSS.

Part 1: Inspect and prepare the PSD

Before writing markup, treat the PSD as a design reference and inventory it systematically.

Map the major regions

• Header and branding
• Primary navigation
• Hero or introductory section
• Main content
• Repeated cards or modules
• Sidebar or supporting content
• Forms and calls to action
• Footer

Classify every visible element

For each layer or group, decide whether it is:

• Content: text, data, headings, labels, or links that belong in HTML.
• Asset: a photograph, complex illustration, logo, or supplied icon.
• CSS-reproducible: a border, gradient, shadow, simple shape, or decorative line.
• Interaction: a button, link, menu, tab, form field, or control requiring behavior.
• Implementation detail: a guide, mask, clipping group, or Photoshop-only effect that should not become a web element.

Record design tokens

Note the canvas size, content width, columns, gutters, vertical rhythm, colors, font families and weights, font sizes, line heights, border radii, shadows, and likely breakpoint changes. Photoshop can expose hexadecimal color values and supports layer- and artboard-level export, making it useful for extracting assets and recurring design values. See Adobe’s Export As overview.

Do not preserve every accidental inconsistency. If the PSD contains twelve nearly identical grays or spacing values, consolidate recurring choices into a coherent token system while preserving meaningful exceptions.

Questions to resolve before coding

• What happens when a heading wraps to two or three lines?
• How does the navigation work on a narrow screen?
• Which rounded rectangles are links, buttons, inputs, or decorative containers?
• What are the focus, error, disabled, loading, and empty states?
• What happens when a card has substantially more text than the reference?
• Which fonts may legally be loaded on the website?
• Should an image be decorative, informative, or a link?
• Which browser and assistive-technology combinations must be supported?

Part 2: Export only the assets you need

Photoshop still provides web-oriented export workflows, but exporting assets is not the same as generating a modern website. Adobe documents File > Export > Save for Web, where you can choose formats such as JPEG, PNG, GIF, or WBMP, adjust quality, preview file size, and save an export without changing the original PSD. Read Adobe’s Save for Web documentation.

Adobe also documents Export As for individual layers, groups, and artboards. Menu labels can vary by Photoshop edition and version; in some current workflows, Save for Web appears under the Export submenu with a legacy label. See Adobe’s Export As guidance.

Export an asset when it is:

• A photograph or complex illustration.
• A decorative image-based background or texture.
• A logo that cannot safely be recreated as text or supplied as vector artwork.
• A complex icon available only as raster artwork.

Prefer HTML, CSS, or SVG for:

• Text and headings.
• Buttons and form controls.
• Simple borders, gradients, shadows, and geometric shapes.
• Decorative lines.
• Clean vector icons and logos when a genuine vector source is available.

Format guide

Format	Use it for
JPEG	Photographs and complex images without transparency
PNG	Transparency, screenshots, and suitable lossless graphics
SVG	Logos and icons supplied as clean vector artwork
WebP or AVIF	Modern raster delivery when project tooling and browser requirements support them
GIF	Specific cases where its limited color range or animation is genuinely appropriate

Never export the whole page as one giant image. Real HTML text is searchable, selectable, translatable, resizable, accessible, and adaptable to different widths.

Use maintainable names

logo.svg
hero-dashboard.webp
icon-arrow-right.svg
team-photo-01.jpg

Avoid names such as Layer 23 copy final2.png, Rectangle 481.png, and slice_07.gif. Include image dimensions where useful, preserve the PSD as the source document, and do not export hidden or unused layers.

Part 3: Build semantic HTML

Map elements according to meaning and behavior, not simply according to their visual appearance.

Design region	Likely HTML
Site header	<header>
Primary navigation	<nav>
Main page content	<main>
Standalone article	<article>
Thematic group	<section>
Supporting content	<aside>
Site footer	<footer>
Main heading	<h1>
Navigation or page destination	<a>
Action that changes state	<button>
Form input	<label> with the appropriate form control
Repeated content	Often <article>, <li>, or a structured <div>, depending on meaning

A rounded rectangle is not automatically a button. Use an anchor for navigation and a button for an action that changes the current page state. Do not use a clickable <div> as a substitute for either.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Example page</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <header class="site-header">
      <a class="site-logo" href="/">
        <img src="assets/logo.svg" alt="Example company">
      </a>

      <nav aria-label="Primary navigation">
        <ul class="site-nav">
          <li><a href="/about">About</a></li>
          <li><a href="/services">Services</a></li>
          <li><a href="/contact">Contact</a></li>
        </ul>
      </nav>
    </header>

    <main>
      <section class="hero" aria-labelledby="hero-title">
        <div class="container">
          <h1 id="hero-title">A clear page heading</h1>
          <p>Supporting copy from the design.</p>
          <a class="button" href="/learn-more">Learn more</a>
        </div>
      </section>
    </main>

    <footer class="site-footer"></footer>
  </body>
</html>

Part 4: Recreate the design with CSS

Start with a small set of tokens and a flexible layout system. Exact values should come from the PSD where the source is reliable, but the implementation should not reproduce every visual accident as a separate hard-coded rule.

:root {
  --color-text: #1f2937;
  --color-background: #ffffff;
  --color-accent: #2563eb;
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 0.75rem;
  --space-4: 1rem;
  --radius-md: 0.5rem;
  --content-width: 72rem;
}

*,
*::before,
*::after {
  box-sizing: border-box;
}

html {
  color-scheme: light;
}

body {
  margin: 0;
  color: var(--color-text);
  background: var(--color-background);
  font-family: system-ui, sans-serif;
}

.container {
  width: min(100% - 2rem, var(--content-width));
  margin-inline: auto;
}

.hero {
  padding-block: clamp(4rem, 10vw, 8rem);
  background: linear-gradient(135deg, #eff6ff, #ffffff);
}

.hero h1 {
  max-width: 12ch;
  margin: 0;
  font-size: clamp(2.25rem, 6vw, 5rem);
  line-height: 1;
}

Use Flexbox for one-dimensional alignment, Grid for two-dimensional page or card layouts, max-width for readable containers, gap for consistent spacing, and clamp(), min(), max(), and minmax() for flexible constraints.

Avoid building the entire page with rules such as:

.element {
  position: absolute;
  left: 437px;
  top: 218px;
}

Absolute positioning may be appropriate for an intentional overlay or decorative detail. It is a poor foundation for the page when text can wrap, fonts can change, content can grow, users can zoom, or the interface must be translated.

Part 5: Make the result responsive

Desktop and mobile screenshots are only a few samples of the final behavior. Your code must also work between those supplied widths.

Responsive implementation checklist

• Choose a mobile-first or desktop-first strategy deliberately; mobile-first is often simpler when the content naturally stacks.
• Use flexible containers and fluid images rather than fixed canvas dimensions.
• Allow navigation to wrap or collapse into a properly labeled keyboard-accessible control.
• Stack columns when their available width becomes too small.
• Use fluid typography where it improves interpolation between reference sizes.
• Keep touch targets large enough to use comfortably.
• Test long headings, translated text, unequal card content, and browser zoom.
• Prevent accidental horizontal overflow.
• Decide how tables, data-heavy layouts, and wide media behave on small screens.
• Respect prefers-reduced-motion when adding animation.

Figma’s current responsive guidance emphasizes auto layout and structured frames to help designs adapt across widths. Those principles are also useful when reconstructing a Photoshop design, even if the source file itself is not a Figma document. See Figma’s responsive webpage guidance.

Do not define “responsive” as “one media query at 768px.” Define behavior at the component level and test the full width range.

Part 6: Typography and fonts

• Identify the exact family and weight used by the design.
• Confirm that the project has permission to use the font on the web.
• Load only the weights and styles the page needs.
• Define a sensible fallback stack for missing or delayed fonts.
• Match line height and letter spacing without forcing fixed text heights.
• Test headings at larger browser text sizes and with longer content.

Fixed-height text containers often match one screenshot and fail everywhere else. Let text wrap naturally, then adjust the surrounding spacing and layout.

Part 7: Images, alt text, and performance

Use real HTML images for content and CSS backgrounds for appropriate decoration. Include intrinsic dimensions to reduce layout shift, select suitable formats, and avoid shipping an oversized export.

<img
  src="assets/hero-dashboard.webp"
  alt="Dashboard showing monthly sales performance"
  width="1600"
  height="900"
  loading="eager"
  fetchpriority="high">

<img
  src="assets/team-photo.webp"
  alt="The product team working together"
  width="1200"
  height="800"
  loading="lazy">

Use concise, functional alternative text for informative images. Use alt="" for purely decorative images. For art direction or significantly different crops, consider responsive image sources. Use object-fit and object-position when the design requires controlled cropping.

Part 8: Accessibility is part of the conversion

A PSD can suggest visual contrast and focus-like states, but it cannot prove that the completed website is accessible. Accessibility depends on the implementation, content, applicable requirements, jurisdiction, and testing. Figma explicitly describes its accessibility guidance as informational rather than legal advice; see Figma’s accessibility guidance.

Implementation checklist

• Use one meaningful <h1> and a logical heading hierarchy.
• Use semantic landmarks such as <header>, <nav>, <main>, and <footer>.
• Write meaningful link text rather than repeated “click here” labels.
• Use visible focus styles and test the entire interface with a keyboard.
• Label every form control.
• Use real buttons for actions and real links for navigation.
• Provide useful alternative text for informative images.
• Do not place essential text in images.
• Check color contrast and do not communicate meaning through color alone.
• Support reduced motion and avoid hover-only interactions.
• Provide accessible validation messages and error recovery.
• Test with a screen reader and the browsers required by the project.

Part 9: Complete implementation path

1. Create the project

project/
├── index.html
├── styles.css
├── script.js
└── assets/
    ├── images/
    ├── icons/
    └── fonts/

2. Audit the PSD

Record dimensions, sections, assets, fonts, colors, spacing, states, and unanswered questions. Do this before attempting pixel-level refinement.

3. Export assets

Use layer, group, artboard, or Save for Web workflows as appropriate. Keep the PSD intact and export only assets that belong in the page.

4. Build semantic markup

Create the document structure and content flow before matching every pixel.

5. Add global CSS

Set box sizing, font loading, base typography, color variables, body defaults, and container rules.

6. Implement the major regions

Build the header, hero, columns, repeated cards, forms, and footer using normal document flow, Flexbox, and Grid.

7. Add responsive behavior

Start with flexible structure, then introduce breakpoints only where the content or component actually needs them.

8. Add interaction

Use real controls and implement keyboard behavior, focus handling, state changes, and accessible announcements where needed.

9. Compare against the PSD

Capture browser screenshots at the reference dimensions, but do not optimize only for one viewport. Visual comparison is one validation layer, not the definition of success.

10. Test failure cases

• Narrow phones and wide monitors
• 200% zoom
• Keyboard-only navigation
• Missing images and slow font loading
• Long and short text
• Different languages
• Forced-color or high-contrast settings where applicable
• Reduced motion
• Touch interaction

11. Validate and optimize

Check console errors, broken links, invalid HTML, CSS warnings, image sizes, loading behavior, layout shift, accessibility, responsive overflow, and the browser versions required by the project.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Part 10: Tutorial collection by skill level

Beginner: PSD inspection and asset export

Start by learning to identify content, decoration, reusable regions, fonts, and genuine image assets. Practice exporting a logo, photograph, and icon without exporting the whole page. Use Adobe’s Save for Web documentation and Export As overview as the current reference for Photoshop’s export workflows.

Beginner: Build a static page with HTML and CSS

Recreate a simple header, hero, call to action, content section, and footer. Focus first on semantic structure, then containers, typography, spacing, and visual refinement.

Intermediate: Convert a multi-column landing page

Use CSS Grid for the primary layout, Flexbox inside components, and a constrained container. Test what happens when the sidebar moves below the main content.

Intermediate: Reconstruct responsive behavior

Take a desktop PSD and explicitly decide how navigation, cards, images, headings, and columns behave at narrow, medium, and wide widths. Test intermediate widths rather than matching only the supplied screenshots.

Intermediate: Bootstrap implementation

Use Bootstrap when its grid and components align with the project and the team values established conventions. Customize its tokens and markup instead of forcing every PSD detail into a prebuilt component.

Intermediate: Tailwind implementation

Use Tailwind when utility classes and precise responsive control suit the project. Normalize repeated PSD values into a design system rather than copying arbitrary values into hundreds of classes.

Advanced: Componentize a multi-page PSD

Identify shared headers, navigation, cards, buttons, forms, and footers. Separate content from reusable structure and establish a single source of truth for repeated styles.

Advanced: Accessibility and semantic HTML

Review heading order, landmarks, links, buttons, form labels, alternative text, contrast, focus behavior, keyboard access, and state announcements. A visual match is not an accessibility audit.

Advanced: Performance and responsive images

Audit image dimensions, modern formats, loading priority, layout shift, font loading, and below-the-fold lazy loading. Do not measure success by visual fidelity alone.

Alternative: PSD to Figma to code

Figma can be useful as a collaborative handoff and responsive-planning layer. Its current guidance covers structured frames, auto layout, accessibility properties, and developer-oriented inspection. However, PSD migration may require manual cleanup, and copied code or snippets remain a starting point for engineering rather than an automatic production implementation.

Alternative: Figma to Webflow

Webflow can suit marketing pages and visual publishing workflows. Its documentation identifies important limitations: the relevant Figma workflow depends on auto-layout layers, custom fonts need to be uploaded to preserve them, imported layer names may influence guessed HTML tags, and responsive adjustments may still be manual. See Webflow’s Figma integration documentation.

Automated conversion: useful scaffold, unsafe shortcut

Evaluate any PSD-to-HTML converter against the output, not its screenshot preview. Inspect:

• Semantic HTML and heading structure
• CSS maintainability and duplication
• Responsive behavior between reference widths
• Keyboard and screen-reader access
• Asset and font handling
• Interaction support
• Framework compatibility
• Commercial-use and licensing terms
• Whether the generated code is genuinely editable

Automated output commonly contains excessive absolute positioning, nested wrappers, incorrect heading levels, div-based buttons, missing alt text, duplicated styles, fixed dimensions, and poor mobile behavior. Treat generated code as a scaffold for review—not proof of a finished website.

Professional PSD-to-HTML services

An agency or freelancer can be appropriate when the team lacks front-end capacity and has a clear specification. Before hiring, ask for a live responsive portfolio and confirm:

• Semantic HTML and accessibility process
• Browser and device testing scope
• Ownership of source code
• CMS or framework experience
• Performance expectations
• Font and image licensing
• Revision and maintenance terms
• Whether the provider supports the target codebase

A static-page service is a poor fit for a product requiring long-term component maintenance, complex application state, or close integration with an existing API and framework.

Troubleshooting common PSD-to-HTML problems

The font does not match

Confirm the family, weight, file format, license, loading path, and fallback stack. A substitute font changes character widths, wrapping, line height, and perceived spacing. Do not compensate by giving text containers fixed heights.

The layout overflows on mobile

Inspect fixed widths, minimum sizes, long unbroken strings, images without a fluid width, grid tracks that cannot shrink, and positioned elements outside the normal flow. Use flexible constraints and test the component at several widths.

Images look blurry

Check the source dimensions, export scale, compression, display size, and device-pixel-density requirements. Do not solve a blurry image by exporting the entire PSD at an unnecessarily large size.

Colors do not match

Check the PSD’s color profile, browser rendering, transparency, export settings, and whether the design uses a blend mode or overlay that needs a different CSS treatment. A sampled color may not represent the final composited appearance.

Transparency disappeared

Confirm that the chosen format supports transparency and that the export did not flatten against a background. PNG or SVG may be more appropriate than JPEG for the asset.

A Photoshop effect cannot be reproduced exactly

Determine whether the effect is essential, whether CSS filters, gradients, shadows, masks, or blend modes can approximate it, and whether a carefully prepared image is more appropriate. Document meaningful visual differences rather than creating fragile markup to chase a single screenshot.

The generated code is too complex

Keep the visual result as a reference, then rebuild the structure. Remove unnecessary wrappers, replace positioned coordinates with Grid or Flexbox, consolidate repeated values, and restore semantic elements.

The PSD has only flattened layers

Use the flattened design for visual reference, but request separate assets, text, fonts, and states wherever possible. If that is impossible, identify which content must be reconstructed manually and which imagery can legitimately remain raster.

What “pixel-perfect” should mean

Pixel accuracy is a prioritization exercise, not permission to compromise the web platform. The correct order is:

1. Preserve hierarchy and intended relationships.
2. Match typography and spacing where the source is reliable.
3. Preserve responsive behavior and content flexibility.
4. Preserve accessibility, semantics, and usable controls.
5. Avoid hacks that make future maintenance fragile.

A page that matches one screenshot but breaks when text wraps, a user zooms, a font is unavailable, or a keyboard user navigates it is not a successful PSD-to-HTML conversion.

Final code-review checklist

• The page contains real HTML text rather than a screenshot of text.
• Content is organized with semantic landmarks and a logical heading hierarchy.
• Links and buttons use the correct native elements.
• Forms have labels, useful errors, and keyboard access.
• Images have appropriate dimensions, formats, loading behavior, and alternative text.
• Layout uses normal flow, Flexbox, Grid, and flexible constraints instead of page-wide absolute positioning.
• Typography survives font substitution, zoom, localization, and longer content.
• The page works across narrow, intermediate, and wide viewports.
• Focus styles, contrast, reduced motion, and non-hover interaction have been tested.
• Unused layers and oversized exports have been removed.
• Generated or framework code has been reviewed rather than accepted blindly.
• Font, image, and code licenses are documented.
• Visual comparison is backed by browser, accessibility, performance, and content testing.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.