What does the _zps suffix on some file names mean?

It is a hash Photobucket appended to many uploaded file names (for example …_zps0a7714e4.jpg). It is part of the real URL, so keep it intact when you paste a link — the archive index stores the full name, suffix and all.

Why do the i-host and s-host numbers always match?

They are two faces of the same Photobucket storage server: i{N} delivers the image bytes and s{N} serves the viewer page for the same content, so s160 and i160 are paired. The build spike confirmed this on real captures.

Is there a URL format for private or newer Photobucket images?

Private albums had no public URL to capture, so they are not in the archive regardless of format. This page documents only the public i{N}/s{N} patterns confirmed against real captures — it does not list unverified or login-gated shapes.

Do I need the http or https version of the old URL?

Either works. The tool normalizes the scheme and matches on the archive's lowercased index key, which ignores http versus https and case. Paste whatever form you have; copying the exact path matters far more than the scheme.

Photobucket image URL formats, explained

A Photobucket image URL reads i{N}.photobucket.com/albums/{shard}/{username}/{path}/{file}: i{N} is the image-bytes host, {shard} is the album-group folder, and {username} is whose album it is. The viewer twin is s{N}.photobucket.com/user/..., where {N} matches. Knowing these parts lets the tool find the archived copy. The catch: only captured URLs recover.

What does an i-host image URL mean, part by part?

The i{N} host is the one that served the actual image bytes, which is why recovery starts here. The number {N} identifies a specific Photobucket image server; the {shard} is a short album-group code; {username} is the account; and everything after is the album path and file name. Photobucket often appended a _zps… hash to the file name.

These are the only image-host patterns this site documents, because they are the only ones confirmed byte-for-byte against the live archive during the build spike. We do not list speculative variants — an unconfirmed pattern is a guess, and guesses do not recover photos.

Anatomy of an i-host image URL (bytes)
Part	Example	What it is
`i{N}`	`i160`	Image-bytes host server number
`albums`	`albums`	Fixed segment for album media
`{shard}`	`t166`	Album-group folder code
`{username}`	`Spinningfox`	The account that owns the album
`{path}/{file}`	`4Chan/117226476488.jpg`	Sub-album path and file

What is the s-host viewer URL, and how is it related?

The s{N} host serves Photobucket's HTML viewer pages — the library and media pages a person browsed, not the raw image. A media page ends in .html and embeds the matching i{N}/albums/... image URL inside it.

The key confirmed fact: the `s{N}` number equals the `i{N}` number — s160 corresponds to i160. So a viewer link tells the tool which image host to query even when you have no direct image URL. That is exactly how username mode discovers a host it would otherwise have to guess.

i-host vs. s-host (both confirmed in the spike)
Host	Serves	Example shape
`i{N}`	Original image bytes	`i1027.photobucket.com/albums/y339/{username}/{file}`
`s{N}` library	HTML album viewer	`s1027.photobucket.com/user/{username}/library/{album}`
`s{N}` media	HTML single-image viewer (embeds the i-host URL)	`s1027.photobucket.com/user/{username}/media/{album}/{file}.html`

Which exact URLs has this tool recovered?

Below are real shapes confirmed against live captures during the build, with the recovery timestamp shown as a mono chip. Each was fetched byte-exact from the archive's raw-bytes endpoint. The example usernames in invented rows are sanitized; the host and shard codes are the genuine confirmed values.

Note the recovery URL form: web.archive.org/web/{timestamp}id_/{original}. The id_ suffix on the 14-digit timestamp tells the archive to return the original bytes rather than a rewritten web-page version — that distinction is what makes a clean download possible.

Confirmed Photobucket URLs and their recovered captures
Original URL pattern	Recovered capture	Result
`i1027.photobucket.com/albums/y339/{username}/blog-with-pip-button_zps….jpg`	`20131130213816`	200×200 JPEG, byte-exact
`i1027.photobucket.com/albums/y339/{username}/ethicalbutton_zps….png`	`20140214103659`	200×200 PNG, byte-exact
`i160.photobucket.com/albums/t166/{username}/4Chan/117226476488.jpg`	`20150907064517`	360×480 JPEG, byte-exact

How do these parts help the tool recover my photo?

For a direct image URL, the tool normalizes it and queries the archive's CDX index for captures of that exact path, preferring a pre-2017 timestamp. For a username, it needs the i{N} host first — derived from one example URL or an s{N} viewer page — then runs a fast, host-scoped search filtered to your /albums/{shard}/{username}/ path.

What it never does is invent a URL you did not have. There is no formula that turns a username into a host without evidence; the whole-site scan that would skip that step times out and strains the archive, so the tool asks for one real link instead.

What can't be recovered

A valid-looking URL isn't a recoverable one: If the archive never captured that exact path, the prettiest URL still returns nothing. Format knowledge points the search; only a real capture produces bytes.
Username alone can't reveal your image host: The i{N} host is part of the URL, not derivable from the name. Without one example link or an s{N} viewer page, host discovery has nothing to anchor to.

Free · no signup · runs in your browser

Decode and recover your URL

Paste a Photobucket image or viewer URL — the tool reads the parts and finds the archived original.

FAQ

Questions people ask

What does the _zps suffix on some file names mean?: It is a hash Photobucket appended to many uploaded file names (for example …_zps0a7714e4.jpg). It is part of the real URL, so keep it intact when you paste a link — the archive index stores the full name, suffix and all.
Why do the i-host and s-host numbers always match?: They are two faces of the same Photobucket storage server: i{N} delivers the image bytes and s{N} serves the viewer page for the same content, so s160 and i160 are paired. The build spike confirmed this on real captures.
Is there a URL format for private or newer Photobucket images?: Private albums had no public URL to capture, so they are not in the archive regardless of format. This page documents only the public i{N}/s{N} patterns confirmed against real captures — it does not list unverified or login-gated shapes.
Do I need the http or https version of the old URL?: Either works. The tool normalizes the scheme and matches on the archive's lowercased index key, which ignores http versus https and case. Paste whatever form you have; copying the exact path matters far more than the scheme.