What Is Forge? Convert Structured HTML Into Platform Themes

Forge is a desktop conversion tool for developers who already have a static HTML design and need to turn it into reusable templates for WordPress or a static-site generator.

It starts with HTML you control. You add explicit data-forge-* attributes to describe partials, content regions, loops, values, and links. Forge reads that structure and generates editable files for the selected platform.

It does not design the site, migrate its content, or hide how the target platform works. The practical job is narrower: convert a finished front-end design into a useful platform-specific starting point without manually rebuilding every repeated template.

Why I Built Forge

Building sites across WordPress and static-site generators such as Pelican, Hugo, Eleventy, and Jekyll revealed the same gap repeatedly.

I prefer to work in HTML. It lets me settle the visual design, responsive behavior, CSS, and component structure before introducing a CMS or generator's template syntax. The problem comes afterward. Each target expects its own layouts, partials, loops, content variables, directories, and asset conventions.

That conversion work is necessary, but much of it follows recognizable patterns. A header becomes a partial or template part. A repeated article row or card becomes a platform loop. A placeholder title becomes a native content expression. Static links and assets need to follow the target's conventions.

Forge grew from that repeated handoff. I wanted to keep HTML as the source design while making the engine-specific output explicit and editable.

How the Conversion Works

The Forge Getting Started guide describes four basic steps:

1. Create a source folder containing the static HTML and assets.
2. Add the markers needed to describe the design's structure.
3. Map the source files and folders in Forge.
4. Choose a documented target and convert the project.

The source can include a home page, a default page layout, named pages, and section-specific list and single-item designs. Forge uses that structure together with the markers rather than trying to guess the purpose of every element.

For example:

<nav data-forge-partial="nav">
  <!-- navigation design -->
</nav>

<section data-forge-loop="blog">
  <article data-forge-item="post">
    <h2 data-forge-bind="title">Example title</h2>
    <p data-forge-bind="summary">Example summary</p>
  </article>
</section>

The navigation marker identifies a reusable region. The loop and item markers identify repeating content. The bind markers identify values that should become platform-specific expressions.

That distinction matters. Forge is marker-driven, not a tool that promises to understand arbitrary HTML automatically.

What the Data Markers Describe

The canonical Data Markers reference documents the current marker groups:

• Partials identify reusable areas such as the head, navigation, footer, and scripts.
• Blocks identify main content, single-page content, protected regions, and the slot where page or post content belongs.
• Loops and items identify repeated collections such as blog cards.
• Binds connect placeholder elements to values such as a title, summary, author, date, image, URL, or category.
• Links identify routes that should be rewritten for the selected engine.
• Platform-specific markers describe behavior that only makes sense for a particular target, such as WordPress menu locations.

Not every site needs every marker. A small site may need only shared partials and content blocks. A publication with several sections may also need loops, bound metadata, alternate single layouts, and pagination handling.

Which Platforms Forge Generates

The established documentation covers five targets:

• WordPress
• Eleventy
• Hugo
• Jekyll
• Pelican

The output differs because the platforms differ. WordPress expects PHP templates and its template hierarchy. Hugo uses Go templates and its layout conventions. Jekyll and Eleventy use their own layout and include structures. Pelican themes use Jinja2 templates.

Forge keeps that engine-specific logic in each exporter. It does not require a Forge runtime after conversion. The generated files remain available for you to inspect, edit, test, and keep in Git.

What Forge Does Not Do

Forge does not remove the need to understand the platform receiving the design.

You still need to:

• Choose an appropriate generator or CMS
• Structure the source HTML and add the necessary markers
• Review the generated files
• Add project-specific configuration and content
• Run the platform's normal build or installation process
• Test routes, assets, templates, accessibility, and responsive behavior
• Deploy the finished site through a separate process

Forge also does not perform a complete content or database migration. It does not guarantee that unmarked, inconsistent, or incomplete source HTML will produce a complete theme. The Troubleshooting guide explains common failures such as missing partial markers, absent content slots, loops without item markers, unresolved links, and missing assets.

That is the tradeoff behind an explicit conversion model. You do a small amount of structural preparation so the output is predictable and maintainable.

When Forge Fits a Project

Forge is worth evaluating when:

• You already have a static HTML design
• You prefer designing in HTML and CSS before writing platform templates
• The site has reusable regions or repeated content layouts
• You need editable output for one of the documented targets
• You expect to inspect and refine the generated files

It is less suitable when you want a hosted site builder, visual content editor, complete content migration, deployment service, or a system that chooses the architecture for you.

For purchased HTML templates, you also need the right to modify and use the source files. Forge changes the technical format. It does not grant additional licensing rights.

Choose Your Next Guide

The most useful next step depends on where you are in the workflow:

• If you are still choosing the applications and generator for a project, start with the website development tools I use to build static sites.
• If the design is finished but its reusable regions and dynamic content are not yet explicit, follow how to structure HTML for theme conversion.
• If WordPress is already the target, continue with how to convert HTML to a WordPress theme with Forge.

Start With a Sample Before Your Own Design

If this workflow matches how you build sites, start with the Forge documentation and choose one established engine.

Download its sample source, convert it without changes, and compare the generated files with the guide's expected output. Once that relationship makes sense, add the same marker pattern to a copy of your own HTML design.

That small test will tell you more than a feature list. You will see the input Forge expects, the files it generates, and the platform work that remains.