Why OG Preview Tools Can Look Different From Real Facebook and KakaoTalk Cards
If the card you see in an OG preview tool doesn't match what actually shows up when you paste the link into KakaoTalk, Facebook, or Twitter, it's tempting to assume "the tool must be broken." But this isn't a bug — it's a structural difference that exists because a preview tool and a real social platform read a page in completely different ways from the start. Here's where that gap actually comes from, based on the OG Preview tool's own code.
1. This tool doesn't fetch the URL directly
The first thing to understand is that this tool doesn't send a network request to the URL you type in and scrape the og tags itself. Looking at the actual code, the parseOGFromHtml() function only scans, with a regex, the HTML string you've pasted into the "HTML Source" tab's textarea and extracts <meta> tags from it — there's no fetch() or XMLHttpRequest call anywhere that requests a URL. The "Manual Input" tab works the same way, requiring you to type in og:title/og:description/og:image/og:url values by hand. In other words, this tool isn't "you enter a URL and a server fetches and analyzes that page for you" — it's "you parse HTML (or values) you already have, and it renders a preview."
It's built this way because of the browser's CORS (Cross-Origin Resource Sharing) restriction. When browser JavaScript sends a fetch() to an arbitrary external site's URL, it can't read the response unless that site's server explicitly allows it via CORS headers. Most ordinary websites don't allow cross-origin fetches like this, so for a free tool that runs entirely in the browser to implement "paste any URL and it auto-fetches and analyzes it," a separate server (a proxy) would need to fetch the page on the tool's behalf. This tool operates purely client-side with no such server component, which is why it's built around you pasting in HTML you've already grabbed yourself — via browser dev tools or "View Page Source."
2. Real platforms each fetch the page with their own crawler
This is where the real difference begins. KakaoTalk, Facebook, Twitter (X), Slack, and similar platforms each send their own crawler bot to a URL the moment you paste a link. These crawlers are entirely different beasts from a browser.
- Different User-Agent: Facebook requests with
facebookexternalhit; KakaoTalk uses its own UA string. If a server is configured to respond differently by UA (e.g. serving server-rendered static HTML to crawlers but an SPA shell to regular users), the "HTML as seen by a browser" that you paste into the preview tool can differ from the HTML the real crawler actually receives. - They check robots.txt and access restrictions: If a path is blocked, the crawler can't even read the og tags and falls back to a default thumbnail or an empty card. Viewing the source directly in a browser never reveals whether this kind of blocking is happening.
- They reprocess image size and aspect ratio themselves: The original image specified by og:image gets fetched again by each platform's own servers and resized, cropped, and cached. If the original aspect ratio doesn't match the recommended 1.91:1, each platform crops from a different position, so the visible image area in the real card can vary slightly by platform.
- Text-length truncation criteria differ: This tool truncates by known rough thresholds like an 88-character Facebook title or a 300-character LinkedIn description, but real services add ellipses at the pixel level based on screen width, font, and language (Korean and English character widths differ), so the tool's character-count cutoff and the real service's actual cutoff don't always line up exactly.
3. Pages that require login, or SPAs, may be unreadable to crawlers at all
The biggest trap is when access to the page itself is blocked for a crawler. If a page only shows its content after login, the crawler has no login session, so it only sees the login page's og tags (or empty defaults). If a React/Vue-style SPA is built so that JavaScript injects the og tags into the <head> only after it runs, a crawler that doesn't execute JavaScript and only reads the initial HTML will never find those og tags. Meanwhile, the HTML a human copies from "View Source" after opening that same page in a browser may already reflect the final state after JavaScript has run (or, if copied from the DevTools Elements tab, the rendered DOM) — so it can look perfectly fine when pasted into this tool, while the real crawler paradoxically reads nothing at all.
To avoid this, og tags need to be statically present in the initial HTML response (as seen via view-source) without requiring JavaScript execution, and the URL needs to be publicly accessible without login. The most reliable approach is to first draft your og tags with the Open Graph Generator, then confirm directly, via "View Page Source" (Ctrl+U), that those tags are actually present in the deployed page's initial HTML.
4. So how should this tool actually be used?
To sum up, this preview tool is a first-pass approximation tool for quickly checking whether your og tags are syntactically correct, whether all six core tags are present, and roughly what tone the card will have. To confirm exactly how it will look on a real platform, you need to also use each platform's official debugger. And if you've already deployed a page, edited its OG tags, and the KakaoTalk/Facebook preview still hasn't changed — that's a different issue from anything covered here: the platform is caching an old crawl result. That caching problem and how to force a re-crawl are covered separately in the guide on why OG caches don't update.
FAQ
Q. If I just enter a URL, will this tool automatically fetch the og tags?
No. There's no fetch or XHR logic in the code that requests an external URL directly. You have to paste the HTML string into the "HTML Source" tab for it to be parsed with a regex, or type values like og:title into the "Manual Input" tab, before a preview can be generated. That's because browser CORS restrictions make it impossible to fetch an arbitrary URL directly without a server-side proxy.
Q. The preview looks fine in the tool, but the image doesn't show up in KakaoTalk.
It's likely that the KakaoTalk crawler couldn't read the page itself (login required, robots.txt blocked, SPA rendered by JavaScript), that the image URL isn't directly accessible (hotlink protection, authentication required), or that the image's file size or aspect ratio falls outside KakaoTalk's internal reprocessing limits. The tool just displays the og:image value from the HTML you pasted as-is — it doesn't verify whether a real crawler can actually access that image.
Q. So how do I check exactly how it'll render on real Facebook or KakaoTalk?
You need to use each platform's official debugger — Facebook's Sharing Debugger, Twitter/X's Card Validator, and so on. These tools actually send that platform's real crawler to the URL and show you the result it fetched, which makes them far more accurate than an approximate browser-based preview. KakaoTalk doesn't offer a public debugger, so the most reliable method is to paste the link into an actual chat room and see what happens.
Q. How should I add og tags to a site built as an SPA (React, etc.)?
Injecting og tags into <head> only after JavaScript runs (client-side rendering only) carries a real risk that crawlers won't be able to read them. You need server-side rendering (SSR) or static prerendering so the og tags are already baked into the initial HTML response itself — that way, even crawlers that don't execute JavaScript can read them correctly.