Can I Copy and Paste HTML Code to a WordPress Website?

Yes, you can paste HTML directly into WordPress. The question that actually matters is where you paste it, because WordPress gives you at least five different places to do it, and each one behaves differently. Paste raw markup into the wrong spot and the block editor will either strip it, escape it into visible text on the page, or wrap it in a paragraph tag that breaks your layout. This happens constantly to people moving code from a tutorial, an embed generator, or an old static site into WordPress for the first time.

Below is what actually works for each method, plus the failure modes nobody warns you about until you hit them.

The Custom HTML Block (Gutenberg)

This is the correct destination for most one-off HTML: a payment button snippet, a third-party widget’s embed code, a custom form someone emailed you as raw markup.

1. Open the post or page in the block editor.
2. Click the plus icon where you want the code to appear.
3. Search for “Custom HTML” and select it.
4. Paste your code directly into the block.
5. Click the Preview tab inside the block to see how it renders before you publish.

The Custom HTML block does not sanitize or interpret your markup, it renders it exactly as typed. That is both the appeal and the risk: a typo in a closing tag can break the layout of everything below it on the page, so always check the preview tab before hitting publish, not after.

One thing that trips people up: pasting HTML into a regular Paragraph block instead of a Custom HTML block. Gutenberg will often try to be helpful and convert angle brackets into their literal text equivalents, so instead of rendering your code, the page displays the tags as visible text. If you see literal `<div>` characters on your published page instead of an actual div, this is almost always what happened.

The Classic Editor’s Text Tab

If your site still runs the Classic Editor plugin, or if you are editing content on an older install, switch from the Visual tab to the Text tab before pasting. The Visual tab runs through TinyMCE’s WYSIWYG processor, which reformats and often mangles raw HTML on paste. The Text tab is a plain textarea; whatever you type or paste lands exactly as-is.

A quirk worth knowing: switching back to Visual after pasting into Text can sometimes trigger TinyMCE to “clean up” the markup, stripping attributes it does not recognize or collapsing empty tags. If you have pasted something delicate, like an iframe with tracking parameters, save the post from the Text tab without switching back to Visual first.

Widgets and the Custom HTML Widget

Sidebars, footers, and other widget areas accept HTML through the dedicated Custom HTML widget.

1. Go to Appearance > Widgets.
2. Locate the widget area you want (Sidebar, Footer 1, and so on, depending on your theme).
3. Add a Custom HTML widget to that area.
4. Paste your code into the widget’s content field.
5. Save.

This is the standard place for things like a chat widget’s install snippet, a small advertising unit, or a custom “follow us” block that a page builder plugin does not handle natively. If your theme is block-based and uses the Site Editor rather than classic widget areas, you will instead drop a Custom HTML block directly into a template part.

Theme Files, for Developers Only

Pasting HTML directly into theme files like header.php or footer.php is the most powerful option and the most dangerous one. A missing PHP closing tag or a stray quote can produce a white screen across your entire site, not just the page you were editing.

If you go this route, three things are non-negotiable. First, use a child theme, never edit a parent theme’s files directly, since any theme update will silently overwrite your changes and wipe out the HTML you added. Second, back up the file (or the whole site) before editing. Third, edit through SFTP or your host’s file manager rather than the built-in WordPress Theme Editor when you can, because the built-in editor has no undo and a syntax error there can lock you out of wp-admin entirely.

A typical pattern for adding a snippet safely:

<?php
/*
Template Name: Custom Landing Page
*/
get_header(); ?>

<!-- your HTML content here -->

<?php get_footer(); ?>

If you are adding styles alongside the markup, enqueue them properly through functions.php rather than pasting a `<style>` block inline. This keeps caching and minification plugins from missing your CSS, which happens fairly often with inline styles buried inside theme HTML.

function my_custom_styles() {
    wp_enqueue_style( 'custom-style', get_template_directory_uri() . '/path-to-your-style.css' );
}
add_action( 'wp_enqueue_scripts', 'my_custom_styles' );

Plugins Built for This

If you find yourself pasting the same snippet across many pages, or you need code to appear sitewide without touching theme files, a dedicated plugin beats manual editing.

Insert Headers and Footers style plugins let you drop tracking scripts, verification meta tags, or global CSS into the head or footer of every page without opening a single theme file. Code Snippets style plugins go further, letting you write and toggle PHP functions independently of your theme, so a theme switch does not wipe out custom functionality the way editing functions.php directly would.

The tradeoff is one more plugin to keep updated. For a single snippet used on one page, the Custom HTML block is simpler and adds no ongoing maintenance. For sitewide code that needs to survive theme changes, a plugin is the better long-term home.

Where People Get This Wrong

Pasting from a word processor. Google Docs and Microsoft Word both wrap plain text in invisible formatting spans when copied. If you are moving HTML from a doc rather than a plain text editor or a code tool, paste it into a plain text editor first to strip the formatting, then copy from there into WordPress.

Assuming JavaScript will run inside a Custom HTML block the same way it runs in a theme file. It generally will, but some security plugins and some hosting-level WAFs strip script tags from post content specifically, even though they leave theme file scripts alone. If a script tag you pasted into a Custom HTML block silently disappears after saving, check your security plugin’s settings for an “unfiltered_html” or “raw HTML” restriction before assuming you made a typo.

Forgetting that multisite installs, by default, restrict the unfiltered_html capability to network admins. On a single-site WordPress install, admins can paste raw script and iframe tags without restriction. On a multisite network, a site admin’s HTML gets filtered through KSES, which strips script tags and several other elements automatically, which explains why identical code works on one install and breaks on another.

Nesting a Custom HTML block inside a Columns or Group block and expecting responsive behavior for free. The HTML you paste renders exactly as written; if it is not responsive markup to begin with (no viewport-relative units, no media queries in an attached stylesheet), wrapping it in a responsive block container does not make the pasted content itself responsive.

Validating and Securing What You Paste

Before pasting anything from an unfamiliar source, run it through the W3C Markup Validation Service. Malformed HTML is usually just cosmetic on a single page, but a stray unclosed tag near the top of a page’s content can occasionally cascade and break elements further down, especially inside a page builder that generates its own wrapping divs.

Treat the source of the code as seriously as the code itself. An embed snippet copied from a legitimate analytics or payment provider is fine. A snippet pasted from a forum post promising a “free traffic hack” is a common vector for injected tracking scripts or outright malware, and it will run with the same privileges as everything else on your site once it is in a post or a theme file. If you would not run an unfamiliar .exe file, do not paste unfamiliar HTML containing script tags either.

Back up before any theme-file edit, every time, even for something that looks trivial. A one-line change to header.php has taken down more WordPress sites than any plugin conflict, mostly because backups get skipped for “quick” edits.

Embedding Third-Party Widgets and Iframes

A large share of “how do I paste HTML into WordPress” questions turn out to be about a specific case: an iframe embed from a booking tool, a survey widget, a map, or a video host that is not YouTube or Vimeo (both of which WordPress handles natively through its built-in embed handler without needing raw HTML at all).

For a generic iframe, the Custom HTML block works fine. Paste the full iframe tag exactly as the provider gave it to you, without trimming attributes you do not recognize, since providers often rely on specific query parameters or sandbox attributes for the embed to function or to pass security checks.

<iframe src="https://example-widget.com/embed/12345"
  width="100%" height="600"
  frameborder="0"
  loading="lazy">
</iframe>

Two things commonly go wrong here. Fixed pixel widths (`width=”800″` instead of `width=”100%”`) will overflow on mobile screens and force horizontal scrolling, so replace fixed widths with percentages whenever the provider’s documentation allows it. And some hosts run Content Security Policy headers that block iframes from unapproved domains outright; if an iframe renders blank instead of showing an error, check your browser console for a CSP violation before assuming the HTML itself is broken.

Page Builders Handle This Differently

If your site runs Elementor, Beaver Builder, Divi, or a similar builder instead of the native block editor, look for that builder’s own HTML widget rather than trying to force the Gutenberg Custom HTML block into a builder-controlled layout. Elementor’s HTML widget, for example, sits inside its drag-and-drop canvas and respects the builder’s column and responsive breakpoint system in a way that a raw Gutenberg block dropped into the same page usually does not.

Mixing systems, pasting a Gutenberg Custom HTML block into a page that is otherwise built entirely in Elementor, tends to produce inconsistent spacing and occasionally duplicate content, because the two editors do not always agree on how a page’s content is structured underneath the visual layer. Pick one system per page and stay inside it.

A Quick Way to Tell Whether Your Paste Worked

After publishing, do not just glance at the page, view the actual rendered source. Right-click the published page and choose “View Page Source,” then search (Ctrl+F or Cmd+F) for a distinctive string from your pasted HTML, like a unique class name or an id attribute. If it is there and intact, the paste succeeded structurally, even if the visual result still needs styling. If the string is missing or has been re-encoded with HTML entities (`&lt;div&gt;` instead of `