Enter a URL
This tool helps you retrieve and inspect the source code associated with a publicly accessible webpage. The source can reveal how the page is structured, which metadata is present, where resources are referenced, and whether important content appears in the initial HTML response.
Source-code review is useful for website owners, editors, marketers and technical teams, but it should be treated as one part of a broader inspection. Modern browsers can modify a page after loading it, and JavaScript may add content that is absent from the server-delivered source.
A source check can help when a search preview uses unexpected wording, a social platform shows the wrong image, a canonical reference appears incorrect, or important page text cannot be found in a browser’s basic source view. It can also support content migrations, template reviews, publishing checks and comparisons between old and new page versions.
For example, an editor preparing a product-page update might confirm that the revised title and description appear in the source. A technical team investigating duplicated URLs might compare canonical references across several page variants. A marketer reviewing campaign pages might look for outdated tracking references or metadata, while avoiding conclusions based on a single request.
The retrieved source may represent the HTML returned to the tool’s request rather than the final document a visitor sees. Server-side rendering usually places more content in the initial response. Client-side applications may return a small document shell and build most of the page after scripts run.
| Observation | Possible Meaning | Follow-up |
|---|---|---|
| Important text is absent | JavaScript may add it, the wrong variant may have been served, or access may have failed. | Inspect the rendered document and network activity. |
| Metadata differs from the browser tab | A script, extension or application state may alter the document. | Compare initial source, rendered markup and publishing settings. |
| Unexpected canonical reference | A template rule, parameter handling or environment setting may be involved. | Check related URL variants and server configuration. |
| Very short or unusual source | The response may be a redirect, challenge, error page or application shell. | Review status, headers and browser behavior. |
Presence in the source does not prove that an instruction will be honored by search services, browsers or social platforms. Likewise, valid-looking markup does not establish that the page is accessible, usable or interpreted consistently.
Use browser developer tools to inspect the rendered document, network requests, console messages and response headers. Test the page with scripts enabled and, where appropriate, disabled. Check mobile and desktop layouts, keyboard access, visible headings, image alternatives, form behavior and navigation.
For technical review, validate structured data with a suitable validator, inspect redirect chains, examine robots controls at both page and header level, and compare canonical and language references across relevant URLs. Review content-management and deployment settings when the source differs from the latest approved version.
Only submit URLs you are authorized to inspect. Do not submit private dashboards, preview addresses, password-reset URLs, signed file addresses, session-bearing links or URLs containing personal information, API keys or access tokens. A submitted address may be processed outside your browser, so treat it as information disclosed to a third-party service.
Source code can expose public implementation details, but it should not reveal passwords, private keys or confidential server configuration. If sensitive data appears in a public response, remove or rotate it through the appropriate system and investigate the exposure. Merely hiding information visually does not remove it from source.
Results may be affected by JavaScript rendering, authentication, cookie consent, bot protection, rate limits, firewalls, geographic routing, device detection, language negotiation, redirects, timeouts and temporary server errors. Content delivery networks and caches may return an older or location-specific version. Personalized, experimental or logged-in pages can vary between requests.
The tool may not reproduce a particular browser, crawler or user session. It also cannot by itself determine whether markup is semantically correct, whether external resources load successfully, or whether a page will be indexed or displayed in a particular way.
No. The source generally reflects the initial response, while the rendered page may include changes made by scripts, browser features and user interaction.
It may be loaded through JavaScript, restricted by location or session, blocked from the request, or absent because an error or redirect was returned.
It can help confirm what appears in the retrieved HTML. You should also inspect headers, rendered markup, publishing settings, caches and the exact URL variant.
Caching, deployments, personalization, experiments, regional delivery, rate limiting and temporary infrastructure conditions can change the response.
It may highlight suspicious public details, but it is not a security assessment. Potential issues should be reviewed by qualified personnel using authorized methods.
No. Avoid submitting authenticated or private URLs, especially addresses containing session data, temporary signatures or confidential parameters.
No. Resource loading, rendering, accessibility, performance, headers, server behavior and user interactions require separate checks.