Blocks are representations of functionality that you can add to any Pen. They are often, but not always, in the form of a processor. For example, Sass, the popular CSS processor, is a Block you can add to a Pen. By adding it, it means that your .scss and .sass files, as well as any other files that may have Sass code inside them, will be processed as Sass.

There are things that add functionality but are not Blocks. Packages from npm are a good example of this. Consider lodash, which provides lots of convincing methods in JavaScript. Lodash is not a Block, it’s a package you can import in your JavaScript. It doesn’t process code, it just adds to your code.

Adding a Block to a Pen

There are several ways to add Blocks to a Pen.

  1. Use a template. Templates may have blocks already added, configured, and ready to go!
  2. Browse the library of Blocks.
  3. Search for a specific Block.
  4. Automatic (see below).

Combining Blocks

Websites tend to be built from a collection of technologies, colloquially known as “the stack”. Many Blocks can be added to a Pen (get it?! A stack of blocks?!) For example, you might talk about a site you build as…

  • … a Next.js site built with React components using TypeScript and styled-components.
  • … an Astro-based site for your portfolio using Markdown-based content and styling things with Less and Open Props.
  • … using Slinkity in order to use Vue components on an 11ty site. Sass is used for styling with deeper browser support via Autoprefixer.

Note that each of the examples above, not all of the technologies are listed as Blocks. Slinkity, Open Props, and styled-components are packages that can be added by importing them, they aren’t a processor in and of themselves.

Automatic Block Adding

Sometimes Blocks are automatically added to your Pen. This happens when you’ve added a file with a file extension that requires a specific processing Block. For example, if you add a file with an .scss file extension, CodePen understands that to mean you need to process that file with Sass. Config files also add blocks automatically, like if the files prettier.config.json or .prettierignore are manually added or uploaded to the root of a Pen, it will automatically add the Prettier block.

We sometimes refer to this as triggering a Block, or generally as the concept of Block Triggers.

Removing a Block from a Pen

If you no longer need a block, you can open the Blocks Panel, click Settings, and then Remove Block.

Unlike adding blocks, CodePen will never automatically remove a block for you. Even if you manually remove a block, the config will remain in place (helpful if you decide to re-add that Block again), but if you know you don’t need it, feel free to delete the config file.

Block Config

Blocks always try to use the industry standard approach for configuration. For example, Babel is configured via a babel.config.json file at the root of your Pen. You can update this file to update the configuration, which will apply the next time your Pen is processed.

Some configuration isn’t file-based. For example, the version of the Block (which typically matches the version of the processor) is updated in the UI.

Sometimes it makes sense for a Block to have file-based configuration, but no industry standard yet exists. Sass is an example of this. For Sass, we place a sass.config.json file into the file system, but we place it within the .codepen directory at the root, as it is a convention invented by us.

Default/Internal Blocks

Default Blocks are Blocks that CodePen automatically adds to Pens to add helpful behavior. They cannot be turned off if the CodePen Compiler determines they are needed.

Validate

The validate block automatically runs to ensure that everything that is required to be present and valid to execute a successful build through the CodePen Compiler is there and ready. This is usually a quick success, but it is the Validate block, for example, that recognizes when you’ve added a new file that requires a new Block, but that Block isn’t added to the Pen yet, so the validation triggers scaffolding of the new files, which will then pass validation on the next build.

Fingerprint

CodePen creates unique file names (your file name with unique fingerprint characters within it) for your static assets, like images, CSS, and JavaScript, so that they can be served with strong caching headers. This is good for performance! This block runs automatically when the compiler sees static files linked to that it can help with.

You may not see the fingerprinted files in the Build Artifacts, as the fingerprinted files are only used when the Pen is served.

Link

After files have been fingerprinted (i.e. had the file name updated uniquely to assist with caching), any links to that file need to be updated as well. For example, a style.css file that becomes style.324ad32.css during fingerprinting needs to update every <link> element in HTML or @import statement in CSS (or anywhere else!) that references that file. The block does that updating automatically.

Packages

If any of your JavaScript uses ESM imports with bare module specifiers (e.g. import { v4 } from "uuid";) the CodePen compiler will see that and add the Packages Block, which creates/maintains a package.json file which injects those dependencies into .html files in the Build Output as an <script type="importmap">.

Inline Block Usage in HTML

Usually Blocks process entire files, but it doesn’t have to be! The CodePen Compiler has the unique ability to process parts of files by Blocks. For example, writing a bit of Markdown within a <div> then going back to HTML, all within one document.

Docs on Inline Block Processing

The Classic Block

There is a special block called Classic that is designed to make the CodePen 2.0 Editor look and behave like the original CodePen editor. The original editor offered three panels: one for HTML, one for CSS, and one for JavaScript. In the HTML panel, you did not have to write a <!DOCTYPE html> or manually link up the CSS and JavaScript. The HTML you wrote was injected into the <body> of a complete template that linked up those things for you, along with other settings and external resources.

The Classic Block offers that same behavior, where you write only the HTML that you want in the <body> and the rest of the document is created for you. The files that it links up are shown and controlled by you in the classic.config.json file.

Requesting New Blocks

Wish we offered a Block that we don’t currently have? Just contact support and we’ll see what we can do.