LinkedIn Post Inspector: What It Fixes and What It Cannot

LinkedIn's Post Inspector, at linkedin.com/post-inspector, reads a URL the way LinkedIn's crawler does and clears the preview LinkedIn had stored for it, so your next share picks up the tags currently on the page. That is the whole job: it refreshes, it does not validate. When the preview is still wrong after you run it, the cache was never the problem. The image you shipped is.

What the Post Inspector actually does

LinkedIn's own help page is unusually precise about the scope. It describes the situation as a preview window showing an old image that is cached, because the URL was shared before, and it offers the Inspector as the way to refresh that URL. Paste, inspect, confirm the preview shows the correct content.

The boundary is right there in the wording. The Inspector re-reads your page and replaces what LinkedIn stored. If the page still says what it said last week, the refresh hands you back the same broken preview and you go around again, blaming the tool.

So there are two failure classes and only one is a caching problem. Either you changed the page and LinkedIn is still showing the old version, which the Inspector fixes in one click, or the page never carried the right tags in the first place, which the Inspector will show you and will not fix.

Which class dominates? I measured 30 pages to find out, and the numbers follow. First the build side, because it is the part you control.

What to ship before you open the Inspector

Do the build side first, because the Inspector cannot conjure a file you never made.

1. One image per page at 1200 by 630, or 2400 by 1260 if you want it sharp on a good screen. Narrower than 1200 puts you outside what works, and the measurement below shows how often that happens.
2. Keep it under 1 MB. JPEG for photographs, PNG for flat type and screenshots. Never SVG.
3. Absolute https URL in og:image, with og:image:width and og:image:height matching the file you really serve.
4. If you declare twitter:card as summary_large_image, ship the image. Otherwise drop the claim.
5. Deploy, then run the Inspector once on the live URL to evict whatever LinkedIn stored earlier.

That order is the whole trick. Run the Inspector before you deploy and all you have done is cache the broken version faster.

If a scheduler publishes for you, nothing changes: the preview is still built from the tags on the page when the post goes out, so you fix them once at the source rather than per post, which is the assumption ReadyToPost works from too. Paste the same link into a cold email instead and the preview matters far less, because the sentence wrapped around it carries everything, the actual engine inside the Tim Ferriss cold email template. Whether a new image changed anything is a click-through question rather than a design opinion, so put it against real numbers with something like PostHog before you redesign twice.

“

The Inspector refreshes what LinkedIn stored. It cannot conjure a file you never made.

”

The measurement: 30 pages, read the way the crawler reads them

On 1 September 2026 I fetched 30 URLs with a LinkedInBot user agent and parsed what came back: og:title, og:description, og:image, and the declared og:image:width and og:image:height. Then I downloaded every image and checked its real dimensions, weight and content type. The sample mixes the guides on the Post Inspector, the platforms a solo builder actually ships on (Ghost, Framer, Carrd, Beehiiv, Substack, Gumroad), a handful of developer products, and my own sites.

Thirty pages is a sample, not a census, and a crawler user agent gets what a crawler user agent gets: canva.com answered mine with a 403 and no tags at all.

The headline numbers: 27 of the 30 pages shipped an og:image. Of those 27, 14 landed within a rounding error of the 1.91:1 shape the large card is built around. The ratios I measured ran from 1.50 to 2.70.

The failure is the image, not the tag

The missing tag is a solved problem. Nearly every page in the sample declares og:image, og:title and og:description, because every CMS and site builder emits them by default now. The relative-path bug that every debugging guide leads with did not appear once: all 27 image URLs were absolute.

What is not solved is the file at the end of that URL.

Two pages served an image narrower than 1200 pixels, which puts them outside what every clean example in the sample does. Two served multi-megabyte files, 2.1 MB and 3.0 MB, for a picture that gets displayed small in a feed. And substack.com points og:image at an SVG icon of roughly 2 KB while declaring it 400 by 400: a vector logo sitting where a preview image belongs.

That declaration gap deserves its own line. og:image:width and og:image:height are hints you write by hand, and nothing checks them against the file you shipped. They are the numbers a debugging tool reads back to you: the ones you are most likely to trust and least likely to verify.

The most useful failure in the set is mine. On measurement day, finngarden.com declared twitter:card as summary_large_image on every article page and shipped no og:image at all. The card was promised, the picture missing. Those pages had been live and correct in every other respect for days, and no amount of cache refreshing would have surfaced it. Only reading the raw HTML did, and the fix went in the same day, at the HTML, not at the Inspector.

The pages teaching the tool fail their own test

This is the part I did not expect. I probed the five blog posts ranking for this query alongside everything else, and not one is within a rounding error of 1.91:1.

• 960 by 540, ratio 1.78, under the 1200 pixel width
• 1095 by 405, ratio 2.70
• 1540 by 1028, ratio 1.50, weighing 2.1 MB
• 1460 by 730, ratio 2.00
• 1774 by 887, ratio 2.00

Five guides on making your LinkedIn preview look right, five previews that will not. The 960 by 540 one is a Framer site, and its image comes off Framer's CDN with width and height set as URL parameters. Nobody sat down and chose 960. A builder default chose it and it shipped, which is the same shape of problem as the ownership question in Base44 vs Lovable: the platform decides something quietly and you meet the decision much later.

The convention is visible in the pages that get it right, though nobody hands it to you. Seven pages in the sample serve exactly 1200 by 630. Three serve 2400 by 1260, the same shape at double resolution. Gumroad sits at 1200 by 627. That cluster is the spec, in practice: ship it, then run the Inspector once.

A preview is the part of your link a reader judges before deciding to click, which is the same reason a follow-up gets judged before it gets read, the case I made in Stop Sending Reminders. Fix the thing that gets seen first.

FAQ

How do I clear the LinkedIn cache for a URL? Open the Post Inspector, paste the live URL, inspect it. That re-reads the page and replaces what LinkedIn stored. There is no separate purge button and no bulk clear.

Why does LinkedIn still show my old image after inspecting? Almost always because the page itself has not changed. Fetch your own URL and look for og:image in the raw HTML. If it points at the old file, or at no file, the Inspector did its job and reported reality.

What image size should I use for LinkedIn previews? 1200 by 630 pixels, or 2400 by 1260 for the same shape at double resolution. That is what the working examples in my sample converge on, and anything under 1200 pixels wide sits outside the pattern.

Does the Post Inspector work for company pages and ads? It inspects URLs, not placements, so it applies anywhere the same link is shared. What it cannot do is change a post already published: those keep the preview they were created with.

Can I check previews without the Post Inspector? Yes, and you should. Fetching your own page and reading its og: tags takes seconds and shows the source of truth. Use the Inspector afterwards, for the one thing it uniquely does: dropping LinkedIn's stored copy of your page.