A Portfolio With a Point of View
Create a visual identity, arrange your work and let visitors filter the projects they want to see.
Edit This ExampleDesign with visual WordPress blocks, write your own HTML, CSS and JavaScript, or bring code from an AI tool. Put the canvas, source editors and live preview to work together.
Create landing pages, portfolios, calculators and interactive sections. Keep the source in WordPress and reuse the parts that work.
Free plugin. Every builder feature included. AI-provider usage is separate.
New in Page Blocks Builder 4
Build on the page, refine the source and move between both as the work changes. The new visual tools connect with the workflow you already know.

This page is built with Page Blocks Builder. View the full-size overview.
Built With HTML, CSS and JavaScript
A page can do more than display content. Try these working examples, then open the same source in the playground and make it your own.
Create a visual identity, arrange your work and let visitors filter the projects they want to see.
Edit This ExampleTurn inputs into useful answers. Build quote tools, estimators and other small calculators with your own formulas.
Edit This ExampleConnect controls to live state. Make checklists, progress trackers and interactive content that responds to each action.
Edit This ExampleThese are browser examples with sample content, built from ordinary HTML, CSS and JavaScript. Accounts, payments and stored application data need the appropriate WordPress backend or external service.
Use your own layouts, responsive CSS, type, color, imagery and motion for a landing page, product story or portfolio.
Add filters, tabs, calculators, galleries and other interactions. Your JavaScript defines what happens next.
Keep a section with its page, reuse it from the library or place it through a shortcode, hook or theme region.
Choose an example, edit the HTML or CSS and watch the preview change. Update the JavaScript and select Run Code to try its behaviour.
Start in the mode that suits the section. Selecting a visual block opens Visual mode; selecting a code section brings its editors into view.
Use native WordPress groups, headings, paragraphs, images and buttons. Edit supported blocks directly in the visual canvas.
Keep HTML, CSS and JavaScript in separate editors beside the preview. Existing code sections retain their original workflow.
Change the page title, slug, and available template from one dialog. These changes travel with the next save, so review the destination before saving.
Export section data as JSON. Import can add sections after the existing ones or replace the page sections; export a backup before using replace.
Supported native blocks are editable on the canvas. Other blocks stay in the document and retain their Gutenberg editing workflow.
Use the same editing actions across a page, and choose the canvas and source ownership that fit the work.
Convert supported sections when you need another editing mode. Native markup is retained; unsupported or ambiguous content stays code.
Reuse an element or move an entire section. Keyboard shortcuts and the editor clipboard support the same workflow.
Choose the Blank canvas template when the page needs no theme header or footer. WordPress asset hooks remain available.
Keep blocks in normal flow, or position and resize on desktop with snapping guides. At 768px and below, Freeform stacks in reading order.
Small editor tools add up when you are adjusting several sections in a row.
Work with line numbers, bracket matching, folding, and separate HTML, CSS, and JavaScript panes. Editor undo is kept separate from document-level section actions.
Insert common elements from the snippet buttons or wrap a selection. In the HTML editor, try section.hero>h1+p followed by Tab for a supported abbreviation.
Use Ctrl/Cmd+Space to request class suggestions from the active theme context, helping you reuse classes your design already supplies.
Cmd/Ctrl+S saves, Cmd/Ctrl+K opens AI, and Cmd/Ctrl+B cycles preview widths. Alt+1, Alt+2, and Alt+3 focus the HTML, CSS, and JavaScript editors.
Shortcuts depend on focus. Code-editor undo and typing shortcuts should work on the text you are editing, while section commands apply to the document.

A section can belong to one page or stay connected to a shared library block. Choose the ownership that fits the job.
A copy is independent. Changing one page’s section leaves the other copies alone.
Use copies for one-off designs. Use linked sections when the same change should reach every placement.
Try the color change, then switch ownership.
Reuse is more useful when you can find a section, see where it is placed, and recover an earlier version.

Search by name, switch between published blocks, drafts, and trash, and sort by recent updates, title, or usage. Grid and list views suit different tasks.
Cards expose the slug, content-type badges, usage count, and copyable shortcode. Inspect the actual placements before changing a shared section.
Give reusable sections clear titles, stable slugs, tags, and descriptions. A slug is easier to recognize in code than a site-specific numeric ID.
Library changes keep revision history with restore support. Revisions help recover code; they are not a replacement for a full backup of placement rules and site settings.
Library shortcodes render published blocks. Keep unfinished shared blocks in draft while you prepare them, then publish only when their placements are ready. A linked block update can affect several live pages at once.
One reusable section can serve a page, a shortcode placement, a WordPress hook, or a theme region. Select an example to see what each route needs.
Use an inline Page Block when the section belongs to one page. Keep blockId at 0 and blockSlug empty so a library reference cannot override its source.
Examples show configuration and syntax. Replace sample slugs and content before using them.
<!-- wp:gt-page-block/page-block {"blockId":0,"blockSlug":"","name":"Contact Section","content":"<section>...</section>","css":"","js":"","phpExec":false} /-->Conditions can narrow placement by post type, page type, and specific post ID. Page types include front page, singular content, archives, search, and 404 contexts.
Positioned blocks and theme regions enforce their conditions. Gutenberg links use respectConditions; shortcode placements use conditions="true" when you want an opt-in check.
Values within a condition group act as alternatives; separate nonempty groups must all match. An empty rule set is broad, so review it before activating a site-wide placement.
Your published page uses the styles and scripts its sections need. Choose delivery deliberately and inspect the code before you save.
Keep small CSS rules inline or give a section its own stylesheet. Use deferred CSS for later content while keeping hero and shared layout styles available early.
The Performance panel reports authored code sizes and duplicate CSS, then flags common image and script loading issues.
These are diagnostics, not a PageSpeed score. Your authored code, media and integrations determine the browser’s work. Some markup checks require WordPress 6.2 or later.
Connect OpenAI, Anthropic, or Gemini when you want help drafting or editing code. Use authenticated REST access when your workflow belongs in a script or an agent.
AI requests can include section content and theme context. Only connect providers and editing tools you intend to use.
pbb/v1GET /wp-json/pbb/v1/blocks
POST /wp-json/pbb/v1/blocks
{
"title": "Footer CTA",
"status": "draft",
"position": "",
"content": "<section>...</section>",
"css": "",
"js": ""
}Illustrative request. Authenticate through the documented WordPress route and use an account with the required permissions.
gt-page-block/page-block[page_block slug="footer-cta"]gt_pb_region()Use the same library objects from WordPress, scripts, or an authenticated agent. Keep permission checks and publication state part of the workflow.
| Method | Route | Purpose |
|---|---|---|
| GET | /wp-json/pbb/v1/blocks | List and search library blocks, with status and pagination filters. |
| GET | /wp-json/pbb/v1/blocks/{id} | Read one library block and its saved fields. |
| POST | /wp-json/pbb/v1/blocks | Create a block. Supply draft status and an empty position while preparing a new reusable section. |
| PUT / PATCH | /wp-json/pbb/v1/blocks/{id} | Update supported fields on an existing library block. |
| POST | /wp-json/pbb/v1/blocks/{id}/duplicate | Create an independent duplicate. |
| DELETE | /wp-json/pbb/v1/blocks/{id} | Move a block to trash by default; permanent deletion is a separate operation. |
| GET | /wp-json/pbb/v1/blocks/{id}/render | Request rendered output subject to the plugin rendering and execution rules. |
Inspect the library or preview a legacy migration from the command line. The sample slug must refer to a real library item on your site.
wp gt-pb block list --status=publish --format=json
wp gt-pb block get footer-cta
wp gt-pb migrate-blocks --dry-runedit_posts; writes require manage_options.REST library fields use php_exec and js_location. Gutenberg attributes use phpExec and jsLocation. They are different API surfaces.
FreeGPL-2.0-or-later
Visual editing, HTML/CSS/JavaScript tools, the reusable library and optional AI are all included.
The store provides a free update key. Activate it for normal automatic updates. AI-provider charges are separate.
Start with one section and a clear job for it to do.
Complete the free checkout and download the plugin.
Activate Page Blocks Builder and allow the post types you want to edit.
Insert a Page Block in Gutenberg or open the visual builder. Save your work and check the published result.
Requires WordPress 6.0+ and PHP 8.1+. Preview with your actual theme, integrations, and page template.
Browse the Source and Releases ↗Editing choices, compatibility and the practical limits.
Yes. The visual canvas, code editors, library and other builder tools work without a license key. The free checkout provides an update key for automatic updates. Optional AI uses your own provider API key, with provider usage billed separately.
You can build supported visual sections with native WordPress blocks. Use HTML, CSS and JavaScript when you want custom layouts, calculators or other interactions. You can also bring code from another tool or use the optional AI assistant.
Yes. Both can sit on the same page, and selecting a section activates its editing mode. Conversion is an explicit choice for supported content. Unsupported or ambiguous markup stays in code, and converted native block code requires 4.1.0 or later.
The plugin works with classic and block themes. Keep the theme’s page shell or choose the Blank canvas template for a page without a header or footer. Named theme regions need matching gt_pb_region() calls in the theme.
Existing code sections, linked library references and legacy Page Block names remain supported. Version 4 does not convert them automatically. You can keep the original code editing workflow and add visual sections when you need them.
You can build the page interface and its browser interactions using HTML, CSS and JavaScript, including tools like the examples above. Authentication, payments, database storage and server processing need the appropriate backend or integration. Optional PHP requires explicit site-level and per-block permission.
Your saved source remains in WordPress, but dynamic Page Blocks and library shortcodes need the plugin to render. Export or rebuild those sections before deactivating it. Ask a product question.
Start with a visual block, a piece of code or one of your own ideas.
Visual freedom. Your code. WordPress underneath.