Security Through Architecture
Most URL shorteners ask you to trust their security practices: encrypted databases, access controls, data retention policies, security audits. But any system that stores your data can be breached. The only truly secure system is one that never has your data in the first place.
thishere.com achieves security through elimination. There is no database to breach, no API to exploit, no user accounts to compromise, and no stored URLs to leak. Your URL is compressed in your browser and encoded into the link itself. The server is a static site that serves JavaScript — it has no endpoint that accepts or returns URL data.
The Security Model Explained
Threat: Server-side data breach — Eliminated. There is no server-side data store. The server serves static HTML, CSS, and JavaScript files. There is nothing to exfiltrate.
Threat: Database compromise — Eliminated. There is no database. All URL data lives in the shortened link itself.
Threat: Man-in-the-middle interception — Mitigated through HTTPS. The compressed URL data in the link path is not meaningful without the decoding algorithm, but HTTPS protects it in transit regardless.
Threat: Account takeover — Eliminated. There are no accounts. No credentials exist to steal.
Threat: Insider access to user data — Eliminated. Even the site operators cannot see what URLs users shorten, because that data never reaches the server.
When to Use a Secure Link Shortener
- Sharing internal company links that should not be stored in a third-party database
- Distributing links containing sensitive parameters (auth tokens, session IDs, API keys in URLs)
- Shortening links in regulated industries where data residency and third-party data sharing are concerns
- Creating shortened links that cannot be revoked by a third party — your links work as long as the decoding site exists
- Any scenario where trusting a third party with URL data is unacceptable
Open and Verifiable
The security of thishere.com is verifiable. Because all URL compression happens in client-side JavaScript, you can inspect exactly what the code does using your browser's developer tools. There are no hidden API calls, no telemetry beacons on the encoding side, and no obfuscated code. The compression algorithm uses standard DEFLATE (RFC 1951) with a domain-specific dictionary — well-understood, deterministic, and auditable.
Frequently Asked Questions
Is the URL encrypted in the shortened link?
The URL is compressed, not encrypted. Compression reduces size but is reversible by anyone with the decoding algorithm. The security comes from the fact that no data is stored server-side, not from the encoding being secret. If you need the destination to be hidden, use an end-to-end encrypted messaging tool.
Can someone decode my shortened link to see the destination?
Yes — anyone with the link can see the destination. That is by design. The security model protects against server-side data collection and tracking, not against a link recipient seeing where the link goes.
What happens if thishere.com goes offline?
Your links would stop working because the decoding JavaScript is served by thishere.com. However, the compression algorithm is open and deterministic, so the links could be decoded by any implementation of the same algorithm.