Website source code Free Tool

Enter a URL

About Website source code

What This Tool Actually Does

This tool fetches the raw HTML of a web page from this site's server and shows it to you in a read-only text box. You type a domain or URL into the single field above, press "Get Source Code", and the server makes an HTTP GET request on your behalf. The response comes back as plain text, HTML-escaped so you see the markup itself in its literal form.

The request is made with a fixed desktop Chrome user agent from the older release line, a Referer of https://www.google.com/, and an Accept-Language header of en-US. The server follows redirects up to one hundred hops, waits up to half a minute for a connection and for the full response, and uses a fresh cookie jar for each request. No JavaScript is executed at any point. What you get is the literal byte stream that the remote server sent back.

You'll see a label above the textarea that reads URL: http:// followed by whatever you typed. The textarea is 570 pixels tall, which is enough for a substantial chunk of markup, though very large pages will require scrolling within the box. There is no syntax highlighting, no line numbers, no download button, and no search function inside the results. The tool is deliberately minimal because its purpose is narrow.

That narrow purpose deserves attention before you interpret any output. When you press Ctrl+U in Chrome or Firefox, you see the source of the page as your browser requested it, with your cookies, your extensions, your IP address, and your HTTPS connection. When you open DevTools and inspect an element, you see the Document Object Model after JavaScript has run, which often bears little resemblance to the original HTML. This tool shows you a third option. It shows you what a server-side anonymous client sees.

The distinction matters for SEO work. Search engine crawlers like Googlebot also fetch raw HTML without executing most JavaScript, at least in the first wave of crawling. They follow redirects, they send a bot-like user agent, and they parse the response bytes directly. So when you want to know what a crawler might encounter before any client-side rendering happens, this tool gives you a close approximation of that experience.

The two live tests run for this rewrite confirm the basic behaviour. Fetching example.com returns the full example.com HTML, complete with the doctype, the title "Example Domain", the inline CSS, and the link to iana.org. Fetching https://www.wikipedia.org/ shows the URL label as http://www.wikipedia.org/, with the scheme downgraded in the display, while the actual fetch follows Wikipedia's redirect to HTTPS and returns the real page. Both tests behaved exactly as the server code dictates.

How to Use This Tool

1. Open the tool page. Find the input box above this article, which is the only field on the page.
2. Enter a domain or URL. Type something like example.com or https://www.wikipedia.org/ into the field. You can include or omit the protocol; the tool will handle it.
3. Press the button. Click "Get Source Code" to submit the form and wait for the server-side request to complete.
4. Read the URL label. Check that the displayed address starts with http://, since the tool forces that scheme regardless of what you typed.
5. Inspect the textarea. Scroll through the raw HTML in the read-only box to examine the title, meta tags, canonical link, hreflang attributes, structured data, and noscript content.
6. Compare with your browser. Open View Source in your own browser on the same URL and note the differences, which usually come from cookies, geo-targeting, or bot detection.

What the Server Actually Does With Your Input

The processing pipeline is short and deterministic. Your input gets trimmed of whitespace and converted to lowercase. If it starts with http:// or https://, that prefix is stripped off. Then the string http:// is prepended, always plain HTTP, even if you typed HTTPS. The www subdomain is preserved if you included it. The result is validated as a URL, and if validation fails, the tool returns the message "Input Site is not valid!".

That forced HTTP prefix catches most people off guard. You might type https://example.com and the label will read http://example.com. The fetch itself starts on HTTP, and then the tool follows whatever redirects the remote server sends. If the site has an HTTP-to-HTTPS redirect configured, which most modern sites do, the tool follows it and retrieves the HTTPS version anyway. If the site only listens on HTTPS and has no HTTP listener at all, the request will fail because there is nothing to answer on that insecure port.

The redirect handling is generous. The server follows up to one hundred redirects, which covers virtually every legitimate redirect chain you will encounter. The connect timeout and the total timeout are both half a minute, so a slow or unresponsive server will eventually give up. SSL certificate verification is disabled, which means the tool will fetch from sites with expired or mismatched certificates that a normal browser would block with a warning page.

Each request gets its own temporary cookie jar. A fresh jar matters because some sites set a cookie on the first response and expect it on subsequent requests. Since the tool makes only one request per submission and discards the cookie jar afterward, any session-based content will not appear. You will see the anonymous, first-visit version of the page.

The user agent is a fixed desktop Chrome string from the release that came out in late 2020. That browser version is several years old as of this writing. Some sites treat older Chrome versions differently from current ones, and some bot-detection systems flag outdated user agents as suspicious. The Referer header is set to https://www.google.com/, which mimics a visitor arriving from a Google search. The Accept-Language header is en-US, so sites that serve language-specific content based on that header will return English.

The request originates from this site's server, which is hosted on Hetzner infrastructure with a Germany-registered IP address. That geographic fact has real consequences. A site that serves different content to German IPs versus US IPs will show you the German version. A site that blocks or challenges non-browser traffic may show you a challenge page. None of this is a bug in the tool. It is the unavoidable result of fetching from a server in a specific location.

Correcting the Old Description of This Tool

The previous version of this page was broadly accurate, but it omitted several mechanical details that matter for interpreting results. The old copy asked whether the tool is the same as Ctrl+U and answered that it is a similar idea with a different requester. That framing is acceptable, though this article goes further into the specifics of who the requester is and what headers it sends.

The old copy correctly stated that the tool does not run JavaScript and that there is a difference between source code and the rendered DOM. Those claims hold up against the server code. What the old copy failed to mention is the forced http:// prefix, which changes the displayed URL and affects which listener the remote server answers on. It also did not mention the fixed Chrome user agent from the older release line, the redirect limit of one hundred hops, the half-minute timeout, or the disabled SSL certificate verification.

Those omissions have practical consequences. If you do not know which user agent the tool sends, you might wonder why a site returns a different layout or a different set of assets than your own browser shows. If you do not know that SSL verification is disabled, you might be puzzled when the tool fetches a page that your browser refuses to open due to a certificate error. If you do not know that the request starts on HTTP, you cannot predict which sites will fail because they have no listener for that protocol.

The old copy also did not explain the cookie jar behaviour or the Referer header. Each submission is a clean, anonymous, first-visit request with a Google Referer. That combination produces a specific class of responses, and knowing the combination helps you interpret what you see. A cookie wall that appears in the tool but not in your browser is understandable once you know that the tool arrives without any cookies from prior visits.

This rewrite does not claim the old version was fictional. It claims the old version was incomplete. A tool description that lists features serves a different purpose than one that explains behaviour under real conditions. This article aims for the latter.

Why the Results Differ From Your Browser

The most common reaction to this tool is confusion about why the output does not match what you see in your own browser. There are several layers to that discrepancy, and each one has a mechanical cause.

Your browser sends a current user agent, often Chrome 120 or later, or Firefox 120 or later, or Safari 17. It sends your cookies, which may include login sessions, consent choices, and tracking identifiers accumulated over years. It connects over HTTPS directly to the site's server. It executes JavaScript, which can modify the DOM, fetch additional content via AJAX, and render client-side frameworks. It sends your IP address, which places you in a specific geographic region and network category.

This tool sends an older Chrome user agent from a Germany-registered server IP. It sends no cookies beyond whatever the remote site sets during this single request. It starts on HTTP and follows redirects. It executes no JavaScript whatsoever. It sends a Google Referer and an English language preference. Every one of those differences can change the response.

Consider a site that uses Cloudflare's bot protection. When the tool's request arrives with an older Chrome user agent from a server IP, Cloudflare may respond with the "Just a moment" challenge page, which contains JavaScript that the tool will not execute. The textarea will show the challenge HTML. Your browser, with its modern user agent and clean reputation, passes the challenge invisibly and shows the real content.

Consider a site that geolocates content. A news site might show German-language articles to the German IP address that this tool uses, while your browser in another country sees English content. A streaming service might block the German IP entirely. An e-commerce site might show different prices or different product availability based on the detected region.

Consider a site with a cookie consent wall. Many European sites, responding to GDPR requirements, show a consent banner to first-time anonymous visitors. The tool's request arrives with no cookies, so the site treats it as a first-time visitor and returns the consent page. Your browser, with its stored consent cookie, skips the banner and shows the full page.

None of these behaviours indicate that the tool is broken. They indicate that the tool is a different kind of client than your browser. The value of the tool comes from seeing what that other client sees, because search engine crawlers are also different kinds of clients.

What Raw HTML Is Good For in SEO

The raw HTML that this tool returns is the foundation of technical SEO analysis. Search engines parse this markup to understand what a page is about, whether it should be indexed, how it relates to other pages, and whether it should appear in rich results. Many of the most important SEO signals live in the HTML head and in the early part of the body.

The title tag is the first element to check. It should be present, unique, descriptive, and within a reasonable length. The tool shows you the exact title that a crawler would read, including any encoding issues or stray characters that might have crept in. A title that looks fine in a rendered browser can look broken in raw HTML.

The meta description tag is next. It does not directly influence rankings, but it affects click-through rates because search engines often use it for the snippet. The raw HTML shows you whether the meta description is present, whether it is truncated by the CMS, and whether it contains the dynamic values you expect.

The canonical link tag tells search engines which URL is the preferred version of the page. Duplicate content issues often come from missing or incorrect canonical tags. The raw HTML shows you exactly what canonical URL the page declares, which you can compare against the URL you requested to spot mismatches.

Hreflang attributes tell search engines which language and regional versions of a page exist. International sites rely on these tags to serve the right language to the right audience. The raw HTML shows you the complete set of hreflang annotations, including any that point to URLs that do not exist or that are missing from the set.

Structured data, also called schema markup, tells search engines about the entity the page represents. Product schema, article schema, FAQ schema, and review schema can all enable rich results. The raw HTML shows you the JSON-LD blocks or microdata attributes exactly as a crawler would parse them, including any syntax errors that would prevent rich results from appearing.

The noscript tag is a fallback for users and crawlers that do not execute JavaScript. If your page relies on JavaScript to inject content, the noscript version is what some crawlers will see. The raw HTML shows you whether your noscript fallback contains meaningful content or just an empty shell.

Raw HTML is the contract between your server and search engines. If the contract is broken, no amount of beautiful rendering in a browser will fix your rankings.

The Client-Side Rendering Problem

Modern web development has shifted heavily toward client-side rendering. Frameworks like React, Vue, and Angular build pages in the browser, fetching data via JavaScript and constructing the DOM dynamically. For users with modern browsers and fast connections, this approach feels smooth and responsive. For search engines and for this tool, it creates a problem.

When this tool fetches a client-rendered page, it receives the initial HTML shell. That shell typically contains a root div, some script tags, and very little else. The actual content, the text and images and links that make up the page, is generated by JavaScript that the tool does not execute. The textarea will show a near-empty document with script tags pointing to the JavaScript bundles.

This is a limitation shared by many crawlers. Googlebot, in its first wave of crawling, also fetches the raw HTML without executing JavaScript. Google has said that it eventually renders JavaScript in a second wave, but that rendering happens later and is subject to resource limits. Bing and other search engines have similar two-stage processes. If your page depends entirely on client-side rendering, you are gambling that search engines will execute your JavaScript successfully and in time.

The practical SEO advice is to use server-side rendering or prerendering for content that matters. The raw HTML should contain the title, the meta description, the main text content, and the internal links. If it does not, this tool will show you exactly what a crawler sees before JavaScript runs, which is often very little.

If you rely on client-side rendering, you should test your pages with this tool to see what the no-JavaScript world looks like. That world includes many crawlers, some social media scrapers, and any user with JavaScript disabled.

Redirects and the HTTP to HTTPS Story

The forced http:// prefix is the most surprising behaviour in this tool, so it deserves a closer look. When you type https://example.com, the tool strips the protocol, prepends http://, and makes the request over plain HTTP. The label above the textarea reflects this, showing http://example.com even though you typed HTTPS.

Because the request starts on http, the tool follows the site's http-to-https redirect when one exists. By starting on HTTP, it can follow the redirect and show you the complete journey from the insecure to the secure version.

Most modern sites have an HTTP-to-HTTPS redirect configured. The server responds to the HTTP request with a permanent or temporary redirect to the HTTPS version of the URL. The tool follows that redirect and retrieves the page over HTTPS. The textarea then contains the HTTPS response, even though the label shows the HTTP URL.

Some sites have a redirect chain that passes through multiple intermediate URLs. The tool follows up to one hundred redirects, which handles even the most convoluted chains. A chain longer than one hundred redirects will not resolve fully.

The failure case is a site that listens only on HTTPS and has no listener for plain HTTP. When the tool sends its request to the insecure port, nothing answers. The connection times out after half a minute, and the tool returns an error. This is not a common configuration, but it exists, particularly for some modern hosting setups that disable HTTP entirely.

For SEO purposes, the redirect behaviour is informative. You can see whether a site uses permanent redirects or temporary ones, whether it preserves the path and query string through the redirect, and whether it redirects to the correct canonical host. A site that redirects http://example.com to https://www.example.com is handling things correctly. A site that redirects to a different domain entirely may have a problem.

Bot Challenges, Cookie Walls, and Geo Content

The three most common reasons why this tool returns something unexpected are bot challenges, cookie walls, and geo-specific content. Each has a distinct signature in the output.

Bot challenges come from services like Cloudflare, Imperva, and Akamai. When these services detect a request that looks automated, they return a challenge page. Cloudflare's challenge page contains the text "Just a moment" and JavaScript that attempts to prove the client is a real browser. Since this tool does not execute JavaScript, the challenge page is exactly what appears in the textarea. The HTML will contain Cloudflare-specific script tags and a cf-chl or similar identifier.

Cookie walls are a response to privacy regulations like GDPR and the ePrivacy Directive. Many European sites show a banner or an interstitial page to first-time visitors, asking them to accept or decline cookies before showing the actual content. Since this tool arrives with no cookies and makes only one request, the site treats it as a first-time visitor and returns the cookie wall. The textarea will contain the consent banner HTML, often with links to privacy policies and cookie settings.

Geo-specific content is a response to the IP address of the requester. This tool's server is hosted on Hetzner infrastructure with a Germany-registered IP address. A site that serves different content to German visitors will show German content. A site that blocks non-US visitors will show a block message. A site that offers different prices by region will show the prices for Germany.

When the tool returns something unexpected, the first step is to check which of these three categories it falls into. The second step is to remember that search engine crawlers face the same categories, though Googlebot has special arrangements with some bot-detection services.

The Live Tests and What They Prove

The live test run for this rewrite used two URLs. The first was example.com, which is the canonical test domain maintained by the Internet Assigned Numbers Authority. The tool returned the full example.com HTML, including the doctype, the title "Example Domain", the inline CSS that styles the page, and the link to iana.org. This test confirms that the basic fetch and display pipeline works correctly.

The second test used https://www.wikipedia.org/. The tool displayed the URL label as http://www.wikipedia.org/, confirming the forced HTTP prefix and the scheme downgrade in the label. The actual fetch followed Wikipedia's redirect to HTTPS and returned the real Wikipedia homepage HTML. This test confirms that the redirect-following behaviour works and that the tool can handle large, complex pages.

These two tests are not exhaustive. They do not test bot challenges, cookie walls, or geo-blocking, because example.com and wikipedia.org do not employ those measures against this kind of request. They do confirm the core mechanics, which is what a rewrite of the tool description needs.

The tool works as designed for straightforward sites. The limitations appear when the target site applies detection, consent, or geo-targeting logic, and those limitations are inherent to any server-side fetch tool.

Limitations

This tool has limitations that come directly from its design. The most significant is that it does not execute JavaScript. For any page built with client-side rendering, the output will be an empty or near-empty shell. You cannot use this tool to see what a page looks like after React or Vue has run.

The second limitation is the fixed Chrome user agent from the older release line. Sites that serve different content to different user agents will show you that older version, which may differ from what current browsers see. Some sites may even block or challenge a user agent that old, treating it as suspicious.

The third limitation is the forced HTTP prefix. Sites that only listen on HTTPS will fail because the initial request goes to the insecure port. The tool follows redirects, so most sites work, but the small minority with no HTTP listener will not respond.

The fourth limitation is the geographic origin of the request. The server is in Germany, so geo-targeted content will reflect a German IP address. If you need to see what a page looks like from a different region, this tool cannot help.

The fifth limitation is the absence of any rendering or interpretation. The output is raw text, HTML-escaped for display. There is no syntax highlighting, no line numbers, no download button, and no search. For very large pages, you will need to scroll through a 570-pixel textarea.

The sixth limitation is the shared site-wide rate limit. This tool has no CAPTCHA and no tool-specific request cap. However, the site applies a throttle to every page. If more than fifteen requests arrive from one IP address within a single second, that address receives a 503 error for the rest of the day. For normal use, this limit will never matter. For automated scraping of this tool, it will.

The SSL certificate verification is disabled. This means the tool will fetch pages with expired, self-signed, or mismatched certificates that a browser would refuse to open. This is useful for testing sites with certificate problems, but it also means the tool cannot tell you whether a site's certificate is valid.

What This Tool Cannot Do

The list of things this tool cannot do is as informative as the list of things it can do. It cannot show you the rendered page. It cannot execute JavaScript. It cannot log in to a site or maintain a session. It cannot send POST requests or interact with forms. It cannot take screenshots. It cannot check whether a page is mobile-friendly. It cannot measure page speed. It cannot verify SSL certificates.

It also cannot bypass bot protection. If Cloudflare or another service challenges the request, the tool will show you the challenge page. The tool does not attempt to solve CAPTCHAs, execute challenge JavaScript, or otherwise prove that it is a real browser. It presents itself as an older Chrome client and accepts whatever response comes back.

It cannot fetch pages that require authentication. If a site sits behind a login wall, the tool will show you the login page. It cannot use your cookies or credentials, because each request gets a fresh, empty cookie jar.

It cannot fetch pages that block server IP ranges. Some sites maintain blocklists of hosting providers and data center IP addresses. If this site's server IP is on such a list, the request will be refused or redirected to a block page.

These limitations are the natural boundaries of a server-side fetch tool. Understanding them helps you interpret the output correctly and choose the right tool for the job.

When to Use This Tool and When Not To

This tool is useful when you need to see the raw HTML that a server delivers to an anonymous, non-JavaScript client. That scenario covers several common SEO tasks. You can verify that your title and meta tags are present in the initial HTML. You can check your canonical and hreflang tags. You can validate your structured data syntax. You can confirm that your noscript fallback contains meaningful content. You can see whether your page depends on JavaScript for critical content.

The tool is also useful for diagnosing redirect issues. You can see whether a site redirects from HTTP to HTTPS, whether it uses permanent or temporary status codes, and where the redirect chain ends. You can check whether a site redirects to the correct canonical host or to an unexpected domain.

The tool is less useful when you need to see the rendered page. If you want to know what a page looks like after JavaScript runs, use your browser's DevTools or a headless browser service. If you want to see how a page renders on mobile, use Chrome's device emulation or a mobile testing tool. If you want to check page speed, use Google PageSpeed Insights or Lighthouse.

The tool is also less useful for pages behind bot protection or cookie walls, because the output will show the challenge or consent page. In those cases, the tool still tells you something valuable, which is that the page is protected, but it cannot show you the underlying HTML.

Match the tool to the question. This tool answers the question "What raw HTML does a server deliver to an anonymous crawler-like client?" It does not answer other questions, and pretending it does will lead to confusion.

Related Tools

When you need to measure the proportion of visible text versus HTML markup on a page, use the Code to Text Ratio Checker, which helps you spot pages that are overweight with code and light on content.

When you want a structured breakdown of the meta tags that this tool shows you in raw form, use the Meta Tags Analyzer, which parses titles, descriptions, and social tags into a readable report.

When you need to see how a page responds to a search engine crawler specifically, use the Google Crawler Simulator, which sends a request with Googlebot's user agent and shows you the response.

Frequently Asked Questions

Why does the tool show http:// even when I type https://?

The tool strips whatever protocol you type and prepends http:// to every request. This design lets it observe the full redirect chain from insecure to secure. The label above the textarea reflects the forced HTTP prefix, while the actual fetch follows any redirects to HTTPS.

Why does the output differ from what I see in my browser?

Your browser sends your cookies, your current user agent, and your IP address, and it executes JavaScript. This tool sends an older Chrome user agent from a Germany-registered server IP with no cookies and no JavaScript execution. Any of those differences can change the response.

Why do I see a Cloudflare challenge page or a cookie wall?

Cloudflare and similar services challenge requests that look automated, and this tool's server-side request looks automated to them. Cookie walls appear because the tool arrives with no cookies, so sites treat it as a first-time visitor. Neither response indicates a tool malfunction.

Can this tool show me what Googlebot sees?

It shows a close approximation. Googlebot also fetches raw HTML without executing most JavaScript, but it uses its own user agent and has special arrangements with some bot-detection services. For a more precise Googlebot view, use the Google Crawler Simulator on this site.

Why does the tool fail on some sites?

Sites that only listen on HTTPS with no HTTP listener will fail because the tool starts on HTTP. Sites that block server IP ranges or that require authentication will also fail. The half-minute timeout means very slow servers may not respond in time.

Does this tool have a request limit?

There is no CAPTCHA and no tool-specific request cap. The site applies a shared throttle to every page, so more than fifteen requests from one IP address within a single second will block that address for the rest of the day. Normal manual use will never approach this limit.