Claude Artifacts HTML: Build and Refine a Working Page

To make an HTML page with Claude Artifacts, describe the page and its behavior, request an HTML deliverable, then test the result before sharing or publishing it. Specify whether you need a visual prototype or a standalone page, because a convincing preview does not establish that its buttons, forms, and external services work.

fenbs can keep the specification and approved revision decisions outside the conversation, so another assistant can continue from the same requirements.

How do you start an HTML artifact?

1. Choose one page and one purpose, such as explaining a workshop and showing its schedule. Supply the actual copy or label missing content.
2. Describe the sections, audience, mobile layout, and required interactions. State which actions are demonstrations and which must work.
3. Ask Claude to create the page as an artifact and name the required deliverable: standalone HTML if that is what you need.
4. Review the first version for correct content and structure before asking for visual polish.
5. Test the page, revise one problem at a time, and check the exported output in the environment where people will use it.

Anthropic includes single-page websites among the outputs in its Artifacts guide↗ (opens in a new tab). Its Claude Design guide↗ (opens in a new tab) describes standalone HTML export. Use the controls available for your artifact type rather than assuming instructions for an older interface still apply.

HTML describes page structure, CSS controls its appearance, and JavaScript adds behavior. You do not need to write all three yourself to review the outcome, but you should know what each part is responsible for. If you want general coding instruction rather than the artifact workflow, use Claude for HTML.

What should you put in the page specification?

Say you are creating a workshop information page for a local design class. Provide its title, audience, schedule, venue, and contact link. Tell Claude whether registration happens on another site; a decorative registration form should not look like a working booking system.

Create a standalone HTML workshop page.
Audience: adults considering an introductory drawing class.
Sections: overview, schedule, materials, accessibility, contact.
Use only the event details supplied below.
Work on narrow phone screens without horizontal scrolling.
Use real headings, labeled controls, and visible keyboard focus.
The Register link goes to the supplied booking URL.
Do not collect or store visitor information.
List external fonts, images, scripts, and other dependencies.

Give acceptance criteria that someone can observe: the booking link opens the correct event, the schedule remains readable on a phone, and every detail matches the approved copy. Avoid vague requests such as professional or modern unless you also provide concrete references.

Ask Claude to identify assumptions before filling gaps. An invented venue, testimonial, or accessibility promise can cause more harm than a rough layout. Keep uncertain details visibly unconfirmed until a person supplies them.

How do you refine the page without losing good work?

Review in passes. First check content and section order. Next check behavior and mobile layout. Then adjust typography, spacing, and color. A request to redesign everything makes it harder to see whether an already correct date or link changed along the way.

Name the exact change and what it should preserve: move the schedule above materials, keep the event details unchanged, and retain the existing registration destination. Ask for a summary of edits, then inspect the actual result rather than relying on the summary.

Keep a known good copy before a substantial revision. Once the workshop organizer approves the wording, record that approval in fenbs so a later design request does not accidentally reopen the content decision.

For other output patterns, see Artifacts examples. The distinction between the finished page and the instructions that produce it is covered in Projects, skills, and Artifacts.

What can a standalone page actually do?

A standalone page can present content and run browser interactions that its code implements. It does not automatically provide account security, reliable shared storage, payment processing, or an email delivery service. Ask what happens behind every control that appears to submit or save information.

A server is a separate system that receives requests and applies business rules. MDN explains the distinction in its introduction to server-side websites↗ (opens in a new tab). If your page needs such a system, define and review it separately before calling the whole experience finished.

Never place a private service credential in an HTML file intended for visitors. Treat sample data as sample data and remove it before a public release. If you need an ongoing application, Claude Code is a separate development workflow to evaluate.

How do you check accessibility and the exported page?

Use the keyboard to reach links and controls. Check that focus is visible and that you can understand the page without relying on color. Review headings in order, meaningful link labels, alternative text for useful images, and labels for any inputs. MDN provides a practical HTML accessibility guide↗ (opens in a new tab).

Open the exported page in a browser and repeat the important checks. Look for missing assets, unreadable text, broken links, and behavior that depended on the original preview environment. Test a narrow window and browser zoom as well as a large screen.

A preview is evidence of what worked in that preview. A release needs evidence from the intended destination. Write down the browser, output version, actions checked, and failures still open so the next reviewer knows the limits of the check.

How to do this with fenbs

1. Create a free account and add a project for the page, including its audience and purpose.
2. Keep the current specification in AI context notes and record the wording or layout decisions a person approves in Decisions and rules.
3. Add tasks for broken behavior, mobile checks, and content review. Save links to the current output and approved assets in Links and listings.
4. Connect your assistant through Integrations, ask it to read the project context, and have it save Where we left off after the revision.

fenbs does not render HTML, host the website, or validate its security. For a single disposable experiment, the chat and a saved file may be sufficient. It becomes useful when the requirements and review decisions must survive several revisions or a change of assistant.

Start with one concrete handoff: the approved copy, the latest file, and the next failing check. More workflows live in AI at work.