Why are Open Graph tags a privacy concern?

Open Graph tags are embedded in the public HTML of every page and are read by social platforms, link previews, and scrapers. Anything you put in og:email, og:phone_number, or a profile tag is fully public and machine-harvestable, even if the visible page hides it behind a login.

What is risky about an og:image URL?

An og:image URL can leak internal structure, such as a private S3 bucket name, a CDN account ID, or a path like /uploads/users/4821/. Scrapers index these URLs, so a predictable path can let an attacker enumerate other users' assets or map your infrastructure.

Should I ever include an author name in og tags?

It depends on context. An author byline on a public blog is fine. The same article:author or og:profile tag on a page in a members-only or internal section can deanonymise staff or users. The tool flags personal-name patterns so you can decide deliberately.

Does this tool fetch my page?

No. It only parses the HTML you paste, entirely in your browser. It performs no network requests and nothing you paste is uploaded, which is important when auditing unpublished pages.

Is a flag always a real problem?

No. Flags are heuristics that surface tags worth a human look. A public contact page legitimately publishes an email; a marketing site legitimately names its author. Treat each flag as a prompt to confirm the exposure is intended.

Open Graph Tag Privacy Auditor

Open Graph and Twitter Card meta tags control how your pages appear when shared, but they also publish structured data into the page source where any scraper can read it. It is easy to leak a contact email, a phone number, a staff name, or an internal asset path into these tags without noticing. This auditor parses the tags you paste and flags the patterns most likely to over-expose content.

How it works

The tool parses your pasted HTML with the browser’s own parser and collects every <meta> element whose property or name begins with og:, article:, profile:, book:, or twitter:. It then runs each tag’s value through a set of privacy heuristics:

Direct contact data — og:email, og:phone_number, and any value matching an email or phone pattern.
Location data — og:latitude, og:longitude, place:location:*, and similar geolocation properties.
Personal names — article:author, profile:first_name, profile:last_name, og:profile, and author-style values.
Infrastructure leakage — og:image, og:url, and og:video URLs whose path looks like an internal upload path, contains a numeric user ID, exposes a cloud bucket host, or uses a non-public CDN pattern.

Each match is reported with the offending tag and a one-line reason. The check is heuristic by design: it surfaces candidates for a human to confirm rather than asserting a definite breach.

Example

Given:

<meta property="og:email" content="[email protected]" />
<meta property="og:image" content="https://internal-cdn.example.s3.amazonaws.com/users/4821/avatar.png" />

The auditor flags the first tag for publishing a direct contact address into the page source, and the second for an image URL that exposes a raw S3 bucket host and a numeric user ID in the path, which a scraper could enumerate.

Tips and notes

Move contact details into a server-side form or an obfuscated, rate-limited endpoint rather than a public meta tag.
Serve social preview images from a neutral public path or a dedicated image proxy so the URL reveals nothing about your storage.
Re-run the audit on staging just before launch — preview tags are often added late and rarely reviewed.
All parsing is local; the tool never fetches or uploads anything.