/en/tool/meta-tags-generator/ works Counts in the browser; our server opens the page
Enter a URL — our server opens the page and sorts its tags into fields, including ones you may have missed. Then edit them: the preview on the right immediately shows how the link appears in Google search results and a messenger card. Length is measured not only in characters but also in pixels — that is what actually determines where the line is cut off.
Place the markup in <script type="application/ld+json"> — the tag with the script
is already included in the HTML export above; a separate file contains the raw object.
Icons are loaded from the same URL shown above in the “Page URL” field.
“Load tags” retrieves the declared list; this button checks each URL and reports whether the file is there.
The root favicon is checked as well /favicon.ico: the browser requests it automatically, even when nothing is declared in the markup.
The scan uses one request per icon. The site's shared limit is three hundred requests per hour from one address, shared by all tools.
On-page details
Page not loaded
The protocol version is the one used to serve the page itself. With HTTP/1.1, a dozen small files are sent in sequence; with HTTP/2 and HTTP/3, they use one connection, so an extra icon no longer costs a separate round trip to the server.
| What | URL | Dimensions and type | Response |
|---|
One page per line. For a URL only, we will fetch the title and description from the site. “URL; title; description” — we will count what you pasted without making network requests.
We fetch no more than fifty URLs at a time: the site-wide limit is three hundred requests per hour from one address, shared by all tools.
List summary
List not checked
The issues are the same as in the top panel: empty, longer than the guideline, wider than the Google line, or the title repeats the description.
| URL | Issues | Title | Description |
|---|
Paste the URL of a finished page and click “Load tags.” The fields will be filled with what is currently on the page—title, description, robots, canonical, og:*, twitter:*, article:*, product:*, theme-color, and language versions—so you edit the live data instead of entering it again.
Choose the page type. It determines og:type, the set of additional tags, and the JSON-LD markup type: an article uses Article with dates and an author, while a product uses Product with a price.
Switch platforms on the right. Google clips the title to the line width, X does not show a description in a large card at all, and LinkedIn never shows one—checking this before publication is cheaper than finding out afterward.
Click “Check” next to the image. The server will report the response code, scheme, protocol version, type, and size; the browser will measure the width and height. You will then see whether the card will be built with or without the image.
Open “Icons and protocol.” The declared list arrives with the tags; the “Check icons” button checks every URL and the root /favicon.ico and reports whether a file exists there.
Get the result in the tab you need: HTML for head, a metadata object for Next.js, useHead for Nuxt, or react-helmet markup. The “Link to set” button puts the entire configuration in the URL so you can send it to someone else.
For many pages, scroll down to batch checking. Check fifty URLs at a time, view a table with lengths in characters and pixels, and export CSV.
The input data is the same as the default field values: you can calculate it mentally and confirm that the tool is telling the truth.
Character headroom: 60 − 45 = 15 for the title and 160 − 140 = 20 for the description. Both values are positive.
Pixel headroom is calculated separately: the title is rendered in Arial 20 px, and Google’s line on a computer is about 600 px wide. The same number of characters can produce different widths, so the counter shows both measures.
The “article” type sets og:type=article, opens the date and author fields, and switches JSON-LD to Article.
The HTML block contains fifteen tags: charset, viewport, title, description, robots, canonical, eight Open Graph tags (including og:image:alt), and twitter:card, followed by JSON-LD markup. The tag count appears in the caption above the listing and changes with the fields.
The “Check” button next to the image adds og:image:width and og:image:height to the tags once the dimensions are measured. Facebook uses them to render the card without waiting for the file to load.
No issues: both lines fit within the character and width limits, and the URLs are complete and use https. Set the title guideline to 40, and an issue will appear along with an ellipsis in the Google card. Click “Check” next to the image, and you will see that no file exists at this URL: example.com returns an error for that request.
Only the URL is sent to the server when you click “Load tags,” “Check” next to the image, “Check icons,” or start a batch check. The server opens the page, returns its parsed data, and saves nothing. Everything else—counters, previews, parsing someone else’s markup, tag generation, JSON-LD, and exports—is calculated in the browser without a single request.
There is no character limit: the line is clipped to fit its width. A line made of “ш” and “щ” is wider than a line made of “i” and “l” with the same number of characters, so “fits in 60” guarantees nothing. Pixels are measured using the same font and size Google uses—Arial 20 px for the title and 14 px for the description. The character counts are shown because people are used to them.
That is how these platforms render it. X shows the image, title, and domain in a large card; LinkedIn shows the image, title, and domain in the feed. The og:description tag is still required: Telegram, Slack, Facebook, ВКонтакте, and search engines read it. The preview shows not what you wrote, but what reaches the person.
The standard size is 1200×630, a 1.91:1 ratio: Facebook, LinkedIn, and X crop images to it. A side shorter than 200 px turns a large card into a small one. Some platforms simply reject files over 5 MB, and an http URL instead of https works almost nowhere. The image field check reports details for the specific file: response code, protocol, type, size, width, height, and ratio.
It protects against accidental duplicates: the same content can open with utm parameters, with and without a trailing slash. Canonical tells search engines which URL to treat as the primary one.
All filled fields—they are stored in the URL hash, the part after the number sign that the browser does not send to the server. You can forward the link, and the recipient will see the same filled-in set. The batch check list is not put in the link: it can contain a hundred lines and does not fit in a URL.
All families are included: title, description, robots, canonical, og:*, twitter:*, article:*, product:*, theme-color, and language versions. The page is read twice: the server returns its ready-made parse, while the page body arrives separately so families missing from the parse can be processed in the browser. An empty field after loading is a response, not an error: that tag is not present on the page. The only content that will not be picked up is what the page adds with a script in the browser: the server sees the markup as it was delivered, exactly as a search crawler sees it first.
An icon is declared in the markup with one line, but the markup does not show whether a file exists at that URL: the image may have been lost during a migration, the tab may have become blank, while the tag remained in place. The button checks every declared URL and reports the response code and size. It separately checks the root /favicon.ico—browsers request it themselves even when nothing is declared—and shows whether there is an apple-touch-icon for an iPhone shortcut, a manifest, and theme-color. The protocol version used to deliver the page is shown alongside them: with HTTP/1.1, small files load in a queue; with HTTP/2 and HTTP/3, they use one connection.
Shows the full path from the URL to the final page and the response codes.
Open