How to Add a Pinterest Feed to Your Website

Most social platforms have quietly made embedding harder over the last few years. Feeds that used to be a copy and paste now want a developer account, a review process, and a token you have to keep alive. It has trained people to assume the answer is always no.

Pinterest is the exception, and it is worth saying plainly at the top: Pinterest still publishes free embed widgets, they need no API key, and nobody has to approve your use of them. If you want your board on your website, the supported route exists and it takes about five minutes.

What almost nobody explains is where that route stops. The widgets are capped, their layout is fixed, and there is a tempting shortcut floating around the internet that will eventually leave you with an empty section on a live page. This guide covers the official markup, the exact limits, the shortcut to avoid, and how to decide when something else is justified.

What People Mean by a Pinterest Feed

Three different jobs share the phrase, and they are not the same amount of work. Separating them first saves a lot of wasted effort.

• Showing Pinterest content on your site. Your board, your profile, or one Pin, displayed on a page you own. This is what the rest of this guide is about, and it is the straightforward one.
• Publishing to Pinterest from your site. Turning your own blog posts or products into Pins automatically. That is the opposite direction, and Pinterest supports it directly through a business account rather than through anything you embed.
• Letting visitors save from your site. The Save button on your images, so a reader can pin your content to their own boards. That is a marketing feature, not a feed, and it is a different add-on.

If the second one is what you actually want, Pinterest documents auto publishing Pins from your own RSS feed in its business help centre, and that is the supported path. Note the direction carefully, because it is the source of a common mix up: that feature reads a feed you publish, it does not give you a feed to read.

The Three Widgets Pinterest Publishes

Pinterest exposes its embeds through a small script and a set of data attributes. One script per page, then one anchor tag for each widget you want. The three that display content are these.

The Board widget is the one people usually mean when they say Pinterest feed, because a board is the unit that actually corresponds to a topic. A profile widget mixes everything you have saved recently, which is rarely what a visitor to a specific page wants to see.

Pinterest documents all three, along with the Save and Follow buttons, in its widgets documentation and its add-ons overview. Both are worth a glance before you build, because the attribute names are exact and a typo fails silently rather than loudly.

Building the Embed by Hand

Four steps, and the whole thing is two tags. Do them in this order and check the page after each one, because a widget that renders nothing gives you no error message to work from.

1. Make sure the board is public. A private board has nothing to render and the widget will simply be empty. This is the single most common cause of a blank widget, and it is worth confirming in a logged out browser window rather than trusting the setting, since your own session sees your private boards either way.

2. Copy the canonical board URL. Open the board on Pinterest and take the URL from the address bar. It has the shape pinterest.com/username/board-name/. Use that exact URL rather than a shortened or shared link, because the widget resolves the board from it.

3. Add the anchor tag where you want the feed. The href is the board URL and the attribute tells Pinterest what to build:

<a data-pin-do="embedBoard" href="https://www.pinterest.com/username/board-name/"></a>

The anchor is intentionally empty. The script replaces it in place, so anything you put between the tags is discarded.

4. Add the script once, near the end of the page.

<script async defer src="//assets.pinterest.com/js/pinit.js"></script>

Once per page, no matter how many widgets you have placed. Including it twice is a real and frequent cause of widgets that render inconsistently, and it is easy to do by accident when a theme already loads it.

Size is controlled with three more attributes on the same anchor: data-pin-board-width, data-pin-scale-height and data-pin-scale-width. Pinterest sets a minimum board width of 130 pixels, a minimum height of 60 pixels with a default of 175, and a minimum thumbnail width of 60 pixels with a default of 92. Leave the board width off and it fills its parent, which is usually what you want inside a responsive layout.

Where the Official Widgets Stop

They work, they are free, and for a lot of sites they are the right answer. These are the walls you will meet, and it is better to meet them on paper than three hours into a build.

• Fifty Pins, and that is the ceiling. The board widget shows up to 50. If your board has 400 Pins and the page is meant to be a browsable archive, the widget is not the tool.
• The layout is Pinterest's, not yours. You get a grid with a header, in Pinterest's styling. You can change the dimensions. You cannot change the arrangement, the typography, the spacing or the colours, and you cannot restyle it from your own CSS because it renders inside Pinterest's own frame.
• No filtering and no ordering. You get the board as Pinterest presents it. There is no way to show only Pins with a particular keyword, or to lead with a specific Pin, or to reverse the order.
• It depends on a third party script at page load. If a visitor blocks trackers, or the script is slow, the section is empty or late. Design the page so an empty widget looks like nothing is missing rather than like something broke.
• One board per widget. Combining several boards into a single unified feed is not something the widget does. You would place several widgets, each with its own header.

None of these are complaints about Pinterest. They are the normal trade of a free, zero configuration embed: you get reliability and you give up control. The question is only whether the control you are giving up is control you needed.

The Save and Follow Buttons, Which Are a Different Job

Two more add-ons sit alongside the three display widgets, and they get confused with them often enough to be worth separating. Neither shows Pinterest content on your page. Both ask your visitor to do something on Pinterest.

• The Save button sits on your images and lets a reader pin them to their own boards. It is a distribution feature: it makes your content easier to spread, and it does nothing at all for the look of your page. If you publish photography, recipes, products or anything else people collect, it is usually a better use of five minutes than a feed is.
• The Follow button asks a reader to follow your Pinterest account. It is one line, it is unremarkable, and it belongs near the feed rather than instead of it.

The distinction matters when you are deciding what a page needs. A feed answers "what do these people have taste in", which is a credibility question. A Save button answers "how do I keep this", which is a distribution one. They are frequently both right, and they are never substitutes for each other.

Both are documented in the same add-ons overview as the display widgets, and both load from the same pinit.js script, so if you already have a feed on the page you have already done the only setup step they need.

Which Pages Deserve One

The technical part of this job is twenty minutes. The part people get wrong is placement, and it is the part that decides whether the section earns its space or quietly costs you.

A Pinterest feed is a signal of activity and taste. That makes it genuinely useful in a small number of places and dead weight in most others.

• An about page, or a studio page. This is where a visitor is actively asking who you are and whether you have judgement. A curated board answers that faster than a paragraph does.
• A portfolio or a lookbook. Where the visual language of your site and Pinterest already agree, and a grid of images is what the reader came for anyway.
• A resources or inspiration page. Where the honest purpose of the page is to send people somewhere useful, and the board is the useful thing.

Where it tends to hurt: product pages, checkout flows, pricing pages, and anywhere else the reader has a specific task in progress. A grid of unrelated images next to a buy button is a set of exits. It also carries a real cost on those pages, because every Pin is an image request competing with the content that actually converts.

The home page is the genuinely arguable one. It works when your site is about taste and the board is tightly curated. It fails when the board is a personal collection that happens to be public, which is the more common case. The test is simple and slightly uncomfortable: look at the last twenty Pins and ask whether you would have chosen every one of them as a statement about your business. If not, use a specific board rather than the profile, or leave it off the home page and put it where the question is being asked.

The RSS Shortcut, and Why to Leave It Alone

Search for this problem and you will quickly find advice to add .rss to a Pinterest URL. It is presented as a clean trick: append four characters to a board or profile address and you have a feed you can pipe into anything.

It has genuinely worked for many years, and that is exactly what makes it dangerous. Here is the honest position on it.

• Pinterest does not document it. It is not in the developer documentation, it carries no compatibility promise, and there is no announcement channel that would tell you if it changed.
• Its behaviour is inconsistent. Whether you get a valid feed varies with the board's privacy, the account, and the region the request comes from.
• Server requests get refused. A URL that returns a feed in your browser frequently returns nothing to a request from a hosting provider or a cloud function, which is precisely where your site would be calling it from.

The practical consequence is that testing it proves very little. It works on your laptop, you ship it, and it either works in production or fails in a way that looks identical to an empty board. Months later it stops, quietly, and nobody notices until somebody asks why the page has a gap in it.

If you want to understand feeds properly and use them where they are actually supported, our guide on how to create an RSS feed covers the format and where it genuinely applies. Pinterest is simply not one of those places on the reading side, however convenient the URL looks. This is a real difference between platforms rather than a universal rule, and it is worth contrasting with adding a Tumblr feed, where the platform does publish open, documented feeds you can rely on.

When the API Is Worth It, and When It Is Not

Pinterest has a real API, and for a certain kind of project it is the right answer. For the job in this guide it is almost always the wrong one, and the cost is not obvious until you are inside it.

Using the API means registering an application, going through Pinterest's review, implementing OAuth, storing tokens, refreshing them before they expire, and handling the case where a token is revoked. That is not a morning of work, and it is not work that ends: it becomes something in your codebase that can break while you are not looking.

What you get for it is control. You can request the content, cache it on your own server, filter it, sort it, merge boards, and render it in your own markup with your own CSS. That is a genuinely different capability from an embed, and if your page depends on any of it, the API is not overkill.

The honest test is this. If you can describe what you want as "my board, on my page, looking reasonable", the widget is the answer and the API is a detour. If you find yourself saying "but only the Pins that", or "sorted by", or "combined with", then you have crossed into API territory, or into using a feed service that has already done that work.

Choosing Between the Four Routes

Every option for getting Pinterest content onto a page falls into one of four buckets. This is the whole decision.

Most people reading this want the first or the second, and the choice between them is not about difficulty, because both are a paste. It is about whether a Pinterest shaped block sitting inside your design is acceptable or jarring. On a portfolio or a recipe site where the visual language is already close to Pinterest's, the official widget often looks perfectly at home. On a site with a strong, distinct design, it tends to read as a foreign object, and that is when a Pinterest feed widget you can style earns its place.

Making It Look Like It Belongs

Whichever route you take, the same handful of decisions separate a section that looks intentional from one that looks bolted on.

• Give it a heading in your own voice. Not "Pinterest", which describes the mechanism. Something that describes the content, like "Things we are collecting this season". The reader does not care which service it came from.
• Match the container, not the contents. You often cannot restyle the inside of an official widget, but you control the space around it. Consistent padding, your own background, and the same maximum width as the rest of the page do most of the work.
• Constrain the height. An unbounded grid of 50 images can dominate a page and push everything meaningful below the fold. Decide how much room the section deserves and hold it to that.
• Mind the weight. Every Pin is an image request. A large board on a page that already carries photography is a real performance cost, especially on mobile, and it is worth measuring rather than assuming.
• Plan for empty. Boards get archived and set to private, and scripts get blocked. The section should collapse cleanly to nothing rather than leaving a heading over a hole.

That last point is the one people skip, and it is the one that eventually shows. A heading with nothing under it is worse than no section at all, because it reads as broken rather than as absent.

Before You Call It Done

Six checks, in the order that catches problems fastest. The first two find most failures.

• Open the page logged out. In a private window, or a different browser. Your own Pinterest session can render a board that the public cannot see, which is how a private board ships unnoticed.
• Confirm the script appears exactly once. Search the rendered page source for pinit.js. Two copies is a real bug and a surprisingly common one when a theme already includes it.
• Check it on a phone. The widget fills its parent by default, so it behaves well in a responsive layout, but a fixed board width you set earlier will not.
• Watch it load on a slow connection. Throttle the network in your browser tools and see what the section looks like before the script has finished. That is what a real visitor on mobile data sees.
• Try it with content blocking on. A meaningful share of visitors block third party scripts. Confirm the page still reads properly with the section missing entirely.
• Come back in a month. Embedded sections fail silently. Put a reminder in your calendar, because the failure mode of every third party embed is an empty space nobody reported.

Do those and you have a Pinterest section that works, degrades quietly when it cannot, and does not become a small piece of technical debt you have forgotten about. That is the whole job.