Image SEO Checker

Free, no signup. Audit image SEO signals visible in raw HTML. Rendered dimensions, real LCP, transfer sizes, and AI alt-text generation are shown honestly as unavailable in this tool.

Built by Patrick Stox

Checks run from our server; we fetch the URL you enter and don't keep the results. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Image Seo Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
  
 
 
Sample report
Illustrative example — based on the markup shown
<img src="hero.jpg">
<img src="divider.svg" alt="" loading="lazy">
<img src="chart.webp" alt="Quarterly traffic by channel" width="960" height="540">
  • Review: hero.jpg has no alt attribute.
  • Observed: divider.svg has empty alt text, which may be correct for decoration.
  • Observed: chart.webp supplies descriptive alt text and dimensions.
  • Not evaluated: actual transfer sizes, rendered dimensions, and the page's LCP element.
 
 
 
How to use it
  1. Enter the public URL containing the images you want to review.
  2. Choose Audit images and inspect each evidence-backed raw-HTML check.
  3. Separate missing alt attributes from intentionally empty decorative alt text.
  4. Use a rendered performance test for any item this report marks not evaluated.
 
 
 
     
     
     
What the results mean
A finding reflects only markup visible in the response. Missing attributes and clearly unsupported patterns require attention; observations such as empty alt text need human context. A pass confirms one implemented rule, while not evaluated explicitly means the tool did not request or render enough evidence.
 
How it works
The checker fetches the public page and parses its raw HTML into a document context. Image-category detectors inspect supported img attributes and ImageObject markup, then return structured severity, summary, and evidence fields. It does not request the image files themselves.
 
Features
  • Alt-attribute coverage and image-markup checks.
  • Loading hints, format clues, and supported ImageObject signals.
  • Evidence from the page source without uploading image assets.
  • Explicit not-evaluated output for render- and network-dependent checks.
 
Limitations
The tool cannot see CSS backgrounds, canvas content, JavaScript-injected images, visual image meaning, file bytes, compression quality, rendered display size, or real performance timing. It cannot write alt text responsibly without seeing and understanding the image in context.
 
Frequently asked questions
Should every image have descriptive alt text?
Every img element should have an alt attributeAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search., but decorative images should usually use an empty alt value. Informative images need concise text that conveys their purpose in context.
Can this tool identify the Largest Contentful Paint image?
No. Actual LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. requires a rendered performance measurement. This checker reports that check as not evaluated rather than guessing from source order or filename.
Does WebP automatically improve image SEO?
No. A modern format can reduce transfer size, but search visibility also depends on relevance, accessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., discoverability, surrounding text, and correct page implementation.
Why are CSS background images missing?
The checker reads image signals in raw HTML. It does not fetch stylesheets or render CSS, so background images and JavaScript-inserted images are outside its evidence set.
 
Next stepContent Gap Analyzer — look up the exact spec and expected values.

Explore more
ToolHeading Structure CheckerToolAccessibility TesterToolLink AnalyzerArticleAlt TextArticleThe HTML lang AttributeArticleRanking in Google Images
 
 
 
Feature requests for Image Seo Checker
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
           
 
Common issues & how to fix them
 
 
 
 
 
Image SEO Checker · one finding
 
First image is lazy-loaded and may be LCP
 
Recommended action: Confirm the actual LCP element first, then remove lazy loading from the above-the-fold LCP image if this image is responsible.
 
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
 
 
 
 Implementation for your setup 
 
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
 
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
 
Steps
  1. Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
  2. Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
  3. For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
  4. For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
  5. For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
  6. Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
  
Verify on this platform
 
  • Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
  • Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
  • Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
 
Rollback
  1. Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
  2. Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
 
Caveats
  • Lab and field data measure different populations and conditions; neither should be relabeled as the other.
  • Core Web Vitals field data is a distribution and can take time to reflect a release.
  • Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Hosted theme, app, tag manager, CDN, or vendor-controlled rendering layer
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Provide the vendor with the affected URL segment, field window, responsible element/interaction, and a reproducible trace.
  • Require a versioned change and repeat the same lab/RUM verification after deployment.
  
Caveats
  • Escalate when the responsible third-party script or hosted template cannot be delayed, removed, configured, or versioned.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Start with representative field data and preserve its page/device/time segmentation.
  2. Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
  3. Deploy one reversible causal change and repeat the same controlled trace.
  4. Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
 
Escalate when
 
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
 
 
 
 
 
 
 
Image SEO Checker · one finding
 
Likely-LCP image lacks high fetch priority
 
Recommended action: Add fetchpriority=high only if performance testing confirms the first image is the above-the-fold LCP image.
 
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
 
 
 
 Implementation for your setup 
 
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
 
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
 
Steps
  1. Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
  2. Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
  3. For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
  4. For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
  5. For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
  6. Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
  
Verify on this platform
 
  • Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
  • Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
  • Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
 
Rollback
  1. Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
  2. Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
 
Caveats
  • Lab and field data measure different populations and conditions; neither should be relabeled as the other.
  • Core Web Vitals field data is a distribution and can take time to reflect a release.
  • Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Hosted theme, app, tag manager, CDN, or vendor-controlled rendering layer
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Provide the vendor with the affected URL segment, field window, responsible element/interaction, and a reproducible trace.
  • Require a versioned change and repeat the same lab/RUM verification after deployment.
  
Caveats
  • Escalate when the responsible third-party script or hosted template cannot be delayed, removed, configured, or versioned.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Start with representative field data and preserve its page/device/time segmentation.
  2. Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
  3. Deploy one reversible causal change and repeat the same controlled trace.
  4. Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
 
Escalate when
 
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
 
 
 
 
  
 
 
     
  •  Warnings Image lacks an alt attribute Fix: Add concise alt text that communicates each meaningful image’s purpose, and use empty alt attributes for decorative images. 
  •  Information Image uses a legacy source format Fix: Compare transfer size and quality, then serve an AVIF or WebP source with a compatible fallback when it materially reduces bytes. 
  •  Information ImageObject markup is absent Fix: Add ImageObject only for a primary image that benefits from structured description, and keep its URL and metadata accurate. 
    •