Is this technique legal?

Yes, from a technical standpoint—you're using public services as documented. However, it may violate the terms of service of specific URL shorteners, especially if used at scale or for purposes they explicitly prohibit (like phishing or malware distribution). Always review the ToS of the shortener you're using. For personal experiments and legitimate throwaway landing pages, you're generally in the clear.

Can shortened URLs be deleted or expire?

Most major shorteners keep links permanently unless they detect abuse or ToS violations. TinyURL has maintained redirects since 2002. However, shorteners reserve the right to remove links that violate their policies, so don't rely on this for mission-critical content. Some shorteners offer paid tiers with guaranteed uptime SLAs.

How do I update content after creating a shortened URL?

You can't. The content is encoded in the URL itself, which is then stored by the shortener. To update content, you must generate a new URL and redistribute it. This makes the technique unsuitable for anything requiring iteration or A/B testing with consistent links.

Why don't browsers block this technique?

URL fragments are a legitimate web standard used for client-side routing, single-page apps, and deep linking. Browsers can't distinguish between a "legitimate" fragment and one containing encoded content. Security happens at the application layer (URL shortener policies, corporate firewall rules) rather than in the browser itself.

What happens if mdview.io or itty.bitty.site goes down?

Your content becomes inaccessible until the rendering service returns. This is a major risk—you're dependent on two services (the shortener and the renderer) remaining operational. For critical content, consider self-hosting a simple hash-decoding page on reliable infrastructure as a fallback.

Can I use this for SEO or long-term content?

No. Search engines don't index content in URL fragments because it's client-side rendered JavaScript. Additionally, shortened URLs pass minimal SEO value, and most shorteners use `rel="nofollow"` on redirects. This technique is explicitly for throwaway, short-term, or private content.

How does this compare to services like Netlify or Vercel's free tiers?

Those platforms are designed for hosting and offer proper analytics, custom domains, SSL, and build pipelines. They're better for anything beyond a quick experiment. This URL fragment technique trades features for zero-friction deployment—no signup, no git push, no build process. Use it when speed matters more than capabilities.

Can I monetize content hosted this way?

Technically yes—you can embed affiliate links, referral codes, or forms that POST to payment processors. However, you'll have no server-side logic, no user authentication, and limited tracking. For real monetization, use proper infrastructure. This works for lead capture or viral campaigns where conversion happens elsewhere.

Are there alternatives to mdview.io and itty.bitty.site?

Yes, though few. Any web app that reads URL fragments can work—you could build your own in ~20 lines of JavaScript. Other options include hash-based routers used in single-page apps, though most aren't designed for arbitrary content rendering. The ecosystem is small because this use case sits in an unusual intersection of client-side rendering and data storage.

What's the best shortener for maximum content capacity?

TinyURL appears to support the longest URLs at around 5,000 characters (though not officially documented), giving you roughly 3,400 characters of Markdown after base64 encoding. is.gd also accepts up to 5,000 characters with no registration required. Bitly's 2,048-character limit is the most restrictive among major services but offers the best analytics on free tiers. However, remember that Chrome and Edge users are limited to 2,083 characters regardless of what the shortener accepts.

URL Shorteners Are Accidentally Permanent Storage

In September 2025, TinyURL announced they were deprecating their 23-year-old unauthenticated API endpoint—the one that handles over a billion requests per month. The reason wasn't traffic or cost. It was abuse. Attackers had figured out something most developers overlook: URL shorteners are permanent storage systems that never delete your data.

I discovered this while trying to ship a landing page for a side project without paying for hosting. The insight was simple but counterintuitive: if you encode content into a URL fragment and shorten it, the shortener stores your entire webpage in their database and serves it indefinitely. You never touch a server.

See example here: https://tinyurl.com/yyyokel

Why This Works

URL fragments—the #hash portion of a URL—never reach servers. They're processed entirely in the browser. Services like mdview.io and itty.bitty.site exploit this by decoding content from fragments using client-side JavaScript. When you visit https://mdview.io/#mdv=base64content, the app extracts the data after #mdv=, decodes it, and renders Markdown with full LaTeX and Mermaid diagram support.

URL shorteners like TinyURL and Bitly accept destination URLs up to a few thousand characters and cache them permanently. Combine these mechanisms: encode your webpage as a fragment, shorten the URL, and the shortener becomes your storage layer. TinyURL has kept redirects alive since 2002 because killing old links breaks the internet.\

The Implementation

// Encode Markdown content
const markdown = `# Product Launch Early access signup. No hosting required.`;
const encoded = btoa(unescape(encodeURIComponent(markdown)));
const url = `https://mdview.io/#mdv=${encoded}`;

// Shorten via TinyURL API or manually
// Result: https://tinyurl.com/abc123

The shortened URL now points to your encoded content. TinyURL stores the full fragment URL in their database. When clicked, it redirects to mdview.io with your content as a fragment. The browser decodes and renders it. No server bills. No maintenance.

Platform Limitations

Different shorteners and browsers impose varying limits on URL length, which directly constrains how much content you can encode:

Service/Browser	Max URL Length	Markdown Capacity (approx.)	Notes
URL Shorteners
Bitly	2,048 chars	~1,400 chars	Hard API limit enforced
TinyURL	~5,000 chars	~3,400 chars	Unofficial, no documented limit
is.gd	5,000 chars	~3,400 chars	No registration required
T.LY	2,048 chars	~1,400 chars	Standard industry limit
Browsers
Chrome	2,083 chars	~1,400 chars	Same as IE/Edge limit
Edge	2,083 chars	~1,400 chars	Legacy IE constraint
Firefox	65,536 chars	~45,000 chars	Best for large content
Safari	80,000 chars	~55,000 chars	Most generous limit
Mobile browsers	Varies widely	~1,000-5,000 chars	Device and OS dependent
Rendering Services
mdview.io	Browser-dependent	Varies by platform	Markdown + LaTeX + Mermaid
itty.bitty.site	Browser-dependent	2-10KB compressed HTML	Uses LZMA compression

The real bottleneck is Chrome and Edge's 2,083-character limit, which means even if a shortener accepts longer URLs, many users won't be able to access them. Firefox and Safari users can handle much larger URLs, but optimizing for Chrome's constraint is the safe approach. Base64 encoding adds roughly 33% overhead, so a 2,000-character URL limit translates to approximately 1,400 characters of raw Markdown content.

For compressed HTML via itty.bitty.site, LZMA compression can fit 2-10KB depending on content complexity and browser support. Results vary significantly by browser—what works in Firefox may fail in Chrome.

Where This Breaks Down

Security teams have caught on. Taiwan's National Institute of Cyber Security reported that from January to September 2025, over 15 million phishing-related threat indicators were collected worldwide, with more than half of the top 10 sources being popular URL shorteners including bit.ly, tinyurl.com, and t.co. The Taiwan-based ppt.cc shortener was exploited in a phishing campaign impersonating a Canadian telecommunications provider, redirecting users to fake login pages designed to steal credentials.

The technique works for phishing because the malicious payload lives in the fragment, decoded only after the redirect completes, so traditional URL or content scanning sees only a benign-looking redirect to mdview.io or itty.bitty.site.

TinyURL's response—retiring their unauthenticated API and adding interstitial preview pages with countdowns for links created via the old endpoint—directly targets this abuse pattern. Their modern authenticated API enables blocking questionable IPs (proxies, VPNs), restricting problematic domains (free webhosts, certain blogging platforms), and enhanced monitoring to combat abuse.

Trade-Offs I Didn't Expect

I shipped three landing pages this way for A/B testing different value propositions. Each took about 5 minutes to deploy. The friction was close to zero compared to setting up DNS, SSL, and a deployment pipeline. But analytics were limited to the shortener's click counts—no behavioral data, no conversion funnels.

Immutability turned out to be both a feature and a constraint. I couldn't update content without generating new URLs, which broke existing shares. For throwaway campaigns, this was fine. For anything requiring iteration, it was a dead end.

The biggest surprise was how shorteners treat these URLs. They don't distinguish between a normal redirect and one containing an encoded webpage. From their perspective, it's just another destination URL. This means your content inherits their uptime guarantees and CDN infrastructure—but also their terms of service and abuse policies.

What I Learned

This technique works best for disposable content: MVP landing pages, viral experiments, time-limited promotions, or immutable documentation snapshots. It fails for anything requiring deep analytics, iterative updates, or user accounts. The zero-friction deployment is seductive, but you're building on infrastructure designed for a different use case.

The security implications are real. I tested encoding a simple form that POSTs to a webhook. It worked perfectly—and immediately made me understand why phishing campaigns exploit this pattern. When major shorteners are whitelisted in corporate environments, and fragment content never leaves the browser, you get an almost ideal delivery channel for anything that wants to avoid inspection.

Platform engineering lessons show up quickly. Deprecating a 23-year-old API handling massive traffic without breaking downstream integrations is non-trivial. TinyURL chose gradual friction—interstitial preview pages and degraded experience for legacy flows—rather than an immediate hard cut-off. The migration path preserves old links while forcing new traffic toward authenticated, more controllable endpoints.

The Broader Pattern

URL shorteners aren't unique. Any service that stores user-provided data and serves it permanently becomes accidental infrastructure. GitHub Issues as a CMS. Discord webhooks as a database. Pastebin as object storage. The pattern is: find a free service designed for one purpose, exploit a side effect, and build on it until they close the loophole.

The ethical boundary is fuzzy. Using this for MVPs or A/B tests feels scrappy. Encoding phishing pages crosses into harm. The technology is neutral, but the platform owners eventually react. TinyURL's API retirement is one snapshot in that lifecycle: discovery, adoption, abuse, crackdown.

I'm not sure where this lands long-term. Part of me appreciates the cleverness—using URL fragments as a content delivery mechanism is genuinely elegant. Another part recognizes that building on unintended behavior creates fragile systems. TinyURL never agreed to be a hosting platform. Using them as one works until it doesn't.

The lesson I keep coming back to: infrastructure designed for one purpose will be repurposed for another. The question isn't whether it's possible—it's whether it's sustainable, ethical, and worth the eventual platform response. For throwaway projects, maybe. For anything you want to last, probably not.