Where Pinterest Actually Stores Your Pins: pinimg.com Explained

Open any pin in a desktop browser, right-click the picture and choose "Copy image address". The address you get does not begin with pinterest.com. It begins with i.pinimg.com. That small detail says a lot about how Pinterest is built, and it explains what a downloader is really doing when it hands you a file.

Two domains with two different jobs

Pinterest runs on two families of hostnames.

pinterest.com (and its country variants such as pinterest.de or pinterest.co.uk) is the application. It serves the home feed, search, boards, comments, notifications, the login flow and the JavaScript that draws the interface. Every page you can bookmark lives here, including the pin page itself.

pinimg.com is the storage and delivery layer. Every image, every video rendition and every thumbnail is served from a pinimg.com hostname. There is no feed, no login and no page to look at, only files.

Splitting an app from its media is a standard pattern for large sites. The app domain needs cookies, sessions and personalisation. The media domain needs none of that; it needs to push the same bytes to a very large number of browsers as cheaply and quickly as possible. Keeping the two apart lets each side be tuned for its own job.

pinimg.com is a content delivery network

A content delivery network is a set of servers spread across many locations that hold copies of the same files. When you open a pin in Madrid, the image is delivered from a server near Madrid. Open the same pin in Sydney and the bytes come from a server near Sydney. The upload itself may have happened anywhere; the CDN spreads copies outward so nobody has to wait on a single origin.

This design has a useful side effect for anyone saving pins. A file at a given pinimg.com address is treated as fixed content: the address names the bytes, so an edge server or a browser can keep a copy without asking whether it changed. The standard Cache-Control header is how a server tells the browser how long that copy may be kept. It also means that once you know a file's real address, fetching it is a plain HTTP request with no application logic in the way.

i.pinimg.com: images and their size folders

Image addresses on i.pinimg.com follow a recognisable shape:

https://i.pinimg.com/736x/ab/cd/ef/abcdef0123456789....jpg
https://i.pinimg.com/originals/ab/cd/ef/abcdef0123456789....jpg

Read from left to right:

Segment	Meaning
`i.pinimg.com`	the image host
`736x` or `originals`	the size folder, named after the width in pixels
`ab/cd/ef`	three short folders derived from the file's hash, used to spread files evenly
`abcdef01....jpg`	the file itself, named by its hash, keeping the upload's extension

The important part is that the hash and the three folders are identical across every size. Only the size folder changes. Pinterest produces scaled copies such as 236x for the feed grid and 474x and 736x for larger views, and it keeps the untouched upload under originals. The scaled copies are what the app shows you most of the time, because a grid of thumbnails does not need full-size files.

That is why "full resolution" on Pinterest is not a setting you switch on. It is a different folder on the CDN. The guide to saving Pinterest images at full resolution goes through how to confirm you received the original rather than a 736-pixel copy, and the image downloader resolves to the originals path for you.

v1.pinimg.com: video renditions

Video is heavier and is handled by a separate host, v1.pinimg.com. When a creator uploads a clip, Pinterest transcodes it into several renditions at different resolutions and bitrates. Those renditions sit on the CDN in two forms: complete MP4 files, and HLS playlists (.m3u8) that point to short segments for adaptive streaming.

The Pinterest app prefers the playlist form because it can switch quality mid-play as your connection changes. You, saving a clip to keep, want the single MP4. Both live on the same host under closely related paths, which is what makes an MP4 download possible in the first place. The article on why Pinterest videos come as M3U8 playlists explains how a downloader locates the MP4 rendition and what happens when only the playlist exists.

A few sibling hosts appear alongside these two. v.pinimg.com turns up for some video assets, and s.pinimg.com serves static files. They belong to the same CDN family and behave the same way: fixed addresses, no login, plain files.

The pin page and the file are different things

A pin URL such as pinterest.com/pin/1234567890/ is the address of a page, not of a picture or a video. The page is HTML and JSON produced by the application. Somewhere inside it is the pinimg.com address of the media.

A downloader's first job, then, is translation. It reads the pin page as a logged-out visitor, finds the media addresses inside it and picks the best one. Its second job is fetching that address. The breakdown of what a Pinterest URL contains covers the first half; everything after that point is a conversation with pinimg.com only.

This also explains a limit you may have hit. A pin on a secret board or behind a login has no page a logged-out visitor can read, so there is no media address to extract, even though the file itself sits on the same CDN.

Why KeepPin only fetches from pinimg.com

KeepPin's download step accepts exactly four hosts: i.pinimg.com, v1.pinimg.com, v.pinimg.com and s.pinimg.com. A request for any other hostname is refused before anything is fetched.

That restriction is deliberate, for three reasons.

It cannot be turned into a general proxy. A service that will fetch any URL you give it becomes a tool for pulling content from unrelated sites through someone else's servers. Limiting the allowed hosts closes that door.
It keeps the file honest. Because the bytes come straight from Pinterest's CDN, what you receive is the file Pinterest serves, not a copy that passed through a re-encoder or a storage bucket.
It keeps the service small. Nothing needs to be stored when the CDN already holds the file and hands it out on request. The overview of how KeepPin works without storing anything describes the three steps and what is and is not logged.

The same idea appears in the privacy policy: the service reads a pin, signs a short-lived link and streams from the CDN. There is no fourth step where a copy lands somewhere.

When the two systems disagree

Because the app and the CDN are separate, they can briefly fall out of step. A pin may be removed from the app while a cached copy of its image still answers on the CDN for a while, or a pin page may still exist while the media address inside it has been replaced by a newer rendition. A downloader that holds an old media address will fail in that second case. The fix is always the same: go back to the pin URL and parse it again, so the translation from page to file happens fresh. The note on why download links expire covers the related case where the link is fine but its signature has run out.

Knowing which host you are looking at also makes troubleshooting faster. If a saved address starts with pinterest.com, you have a page, and the video downloader needs it. If it starts with i.pinimg.com or v1.pinimg.com, you already have a file address, and the only question left is which size folder or rendition it points to.