Turn one URL into anything
Thirty-one tools for everything a URL can become: its raw HTML, clean text, Markdown, structured JSON or XML, a screenshot, a PDF, or a QR code — plus tools to inspect its meta tags, heading outline, links, and IP addresses without opening it. Every live-fetch tool here runs server-side, so it works even on sites that block cross-origin requests from a browser. Round it out with a combined multi-scheme encoder/decoder and the focused single-purpose tools underneath it.
The short answer
iotools.cloud has a dedicated tool for turning any live URL into HTML, Markdown, plain text, JSON, XML, a screenshot, or a PDF, plus tools that inspect a URL's meta tags, heading hierarchy, links, and IP addresses without opening it — all fetched server-side, so they work even on pages that block cross-origin requests from a browser. A separate set of encode/decode tools (Base64, hex, binary, ROT13, JWT, HTML entities, and a combined multi-scheme picker) handles the raw text transformations a URL-related task often also needs, entirely in your browser.
See what's really on a page
inspect a URL without opening itThese fetch the live page server-side and hand back structured facts — the meta tags, the heading hierarchy, every link, and the IP addresses behind the domain — without you opening dev tools or view-source.
Convert a URL into another format
the page's content, re-typesetGive any of these a live URL and get back the page's content in the format you actually need — raw HTML for scraping, Markdown for a wiki, clean text for reading, or structured JSON/XML for a script.
Turn a URL into an image, PDF, or code
share it as a fileSometimes you don't want the content, you want a file — a screenshot to drop in a doc, a PDF to archive, or a QR code someone can scan straight to the link.
Open, summarize, and pull links from text
work with more than one page at a timeFor when the unit of work isn't one page but many — opening a batch of links at once, getting AI's take on a long page without reading it, or pulling every URL out of a block of pasted text.
Encode or decode in one tool
one scheme picker instead of eight toolsURL, Base64, JWT, Hex, Unicode, Binary, ROT13, and HTML entities, from one dropdown — for when you don't want to hunt down which single-purpose tool handles which format.
Encode or decode one scheme at a time
the focused, single-purpose versionsThe same schemes as dedicated tools, each with the full option set — delimiters, casing, algorithms — that a combined picker leaves out.
Why these tools fetch instead of asking you to paste
A browser can't just fetch an arbitrary page from JavaScript and read its response — cross-origin requests are blocked by CORS unless the target site explicitly opts in, which most sites don't. That's why URL to HTML, URL to Text, URL to Markdown and every other tool in the first three sections of this page run the fetch on our server instead: you give it a URL, the server fetches the page, and the result comes back to you. It works the same way whether the target site cooperates with cross-origin requests or not.
The tradeoff is that none of these see what JavaScript adds to a page after it loads — they read the HTML the server returns on the very first request, the same thing `curl` would see. For a page that renders its real content client-side, the extracted text, headings, or links will be thinner than what you'd see in a browser tab.
Picking the right output format
The five conversion tools overlap on purpose — they're not five ways to do the same thing, they're five different shapes of the same content, and the shape you want depends on what happens next.
- Reading it yourself
- url-to-text — no markup, no nav, just the words
- Pasting into a wiki or README
- url-to-markdown — headings and links survive as Markdown syntax
- Feeding a scraper or archiving
- url-to-html — the exact HTML the server sent, untouched
- Driving a script or test fixture
- url-to-json or url-to-xml — title, headings, and links as data, not prose
- Getting the gist without reading it
- url-summarizer — the same fetch, condensed by AI into a short summary
None of these re-fetch the page differently — they extract from the same HTML, just packaged for a different next step.
A screenshot and a PDF are not the same job
URL to Image and URL to PDF both turn a URL into a downloadable file, but they solve genuinely different problems and it's worth knowing which one you actually want before you click either.
- 1Expecting url-to-pdf to look like the webpage
It won't — there's no image, no original colors, no original layout. It's closer to "print the article text" than "print the page". If a visual copy matters, use url-to-image, or your browser's own Print to PDF.
- 2Assuming a screenshot captures what YOU see logged in
The rendering service fetches the page anonymously, the same as any other visitor without your session. Content behind a login won't appear in the screenshot any more than it appears to url-to-text.
Encoding a URL's pieces is a separate skill from fetching it
A URL often carries encoded data inside it that has nothing to do with fetching the page — a Base64 payload in a query string, a JWT in an Authorization header you copied out of a request, a percent-encoded path segment. Universal Decoder and Universal Encoder cover exactly that: eight schemes behind one scheme picker, running entirely in your browser with no network call at all — a completely separate job from every tool above it on this page.
If you already know which scheme you're dealing with and want more control than a combined picker gives you — a specific hex delimiter, a choice of JWT algorithm, the ability to check a value against its date claims — the single-purpose tools in the last section have the fuller option set. None of these schemes are encryption: Base64 Decode, Hex to Text Converter, and ROT13 Encoder / Decoder are all reversible by anyone with no secret required, which is worth knowing before relying on one to "hide" something.
Which one do I want?
Several tools here overlap. The short version:
| url-to-text vs. url-to-markdown | You want plain, readable prose with no markup at all | You want structure preserved — headings, links, and lists — to paste into a wiki or README |
|---|---|---|
| url-to-image vs. url-to-pdf | You need a visual screenshot of exactly how the page renders | You need a readable document to archive or send — content, not pixels |
| universal-decoder vs. a single-scheme tool | You're not sure which encoding you're looking at, or you switch between schemes often | You already know the scheme and want its full option set (hex delimiters, a JWT claims table, …) |
| url-extractor vs. url-to-links | You already have the text or HTML and just need the URLs pulled out of it | You have a live URL and want that page's actual on-page links, resolved to absolute URLs |
Why this set
Every live-URL tool here fetches server-side, so it works on sites that block cross-origin requests in a browser — no dev tools, no view-source gymnastics.
Every fetch runs through the same SSRF guard: no localhost, no private IP ranges, no cloud-metadata endpoints — whether you're extracting text or taking a screenshot.
HTML, Markdown, plain text, JSON, XML, an image, or a PDF — stop hunting for which converter handles which format.
Questions
Do any of these tools need me to sign in?
Only the AI URL Summarizer, since it calls a paid AI model on every run. Every other tool on this page — including every live-fetch conversion and inspection tool — is free and available to guests.
Why does the extracted text sometimes look thin or incomplete?
These tools read the HTML a server returns on the first request — they don't run the page's JavaScript. A page that renders its main content client-side will extract thinner than what you'd see in a browser tab.
Can I fetch a page that requires a login?
No. Every fetch here is anonymous, the same as any visitor without a session — content behind a login wall won't appear in the result.
What's the difference between URL to Image and just using my browser's screenshot tool?
Nothing conceptually — URL to Image calls a rendering service to do the same job, so you don't need to open the page yourself. It's most useful for automating a screenshot (e.g. from a script) rather than a one-off you could take by hand.
Is Base64/hex/binary encoding the same as encryption?
No — none of the schemes in the encode/decode sections here provide any security. They're all fully reversible by anyone with no secret required. If you need to actually protect something, use real encryption (AES) instead, not an encoding scheme.