Announcing Secure URLs: Pre-Authenticated and Immutable URLs

Henri Cook -

Today we're excited to announce a new feature set for all Bytescale users: Secure URLs.

Secure URLs are a new way to access private files in your Bytescale account. Instead of using Authorization headers, you can now generate pre-authenticated URLs. This makes it easier to share private files in places where setting custom headers isn’t practical — such as image tags, emails, and chat apps.

Secure URLs include four parts: Signed URLs, Encrypted URLs, Expiring URLs, and URL Metadata. You can use them separately or together, depending on what you need.

Why use Secure URLs?

Secure URLs solve a number of limitations that come with header-based authentication:

  • Better cache performance: Header-based auth often breaks caching. Secure URLs can be generated the same way every time, so cache hits are shared across users.
  • Easier file sharing: You don’t need custom headers. Just drop the link in an <img> tag, email, or chat — and it works.
  • Immutable URLs: You control exactly what the user can access. Users can’t change file paths or transformation parameters.
  • Built-in tracking: Add metadata to trace where links are used or leaked, and set expiration times to limit access if they are.
  • Obfuscation with Encrypted URLs: Hide file names, paths, and transformations from the public. Great for privacy or hiding how assets are served.
  • Granular, dynamic permissions: Permissions are decided when the URL is created. Your backend can check user roles, memberships, or subscription status on the fly.

Signed vs Encrypted URLs

There are two types of Secure URLs you can use: Signed URLs and Encrypted URLs.

  • Signed URLs keep the URL readable but make it tamper-proof. A cryptographic signature and expiration timestamp are added to the URL. If anyone tries to change it, the signature will no longer match, and the request will fail. The API key that signs the URL defines which files the user can access.
  • Encrypted URLs hide the entire query string. This protects file paths and transformation parameters from being seen. Just like Signed URLs, Encrypted URLs are pre-authenticated using an API key. The main difference is that file transformation details – and optionally file path details – are hidden from the user.

In general, we recommend using Signed URLs unless you have a specific need to hide the contents of the URL. Signed URLs are simpler to implement and easier to debug, since everything is visible in plaintext.

Extra features: Expiring URLs and URL Metadata

Secure URLs also support expiration and metadata.

  • Expiring URLs automatically stop working after a time you choose. This helps prevent links from being reused or shared later. The expiration time is built into the signature or encrypted payload, so it can’t be removed or changed.
  • URL Metadata lets you include extra meta-* query parameters. These are useful for logging or tracking. They don’t affect caching or transformation. If you use them with Signed or Encrypted URLs, they can’t be modified by users.

For example, you could generate a URL like .../file.jpg?meta-user=42&sig=... to track which user received the link. If it’s shared somewhere, you’ll know who it came from. When combined with Signed or Encrypted URLs, the metadata will become an immutable part of the URL, so can’t be removed or altered by the user.

Available Now

Secure URLs are available now on all Bytescale plans, including the free plan.

You can get started today by generating Signed URLs or Encrypted URLs using your API key. We’ve added full examples and code snippets to the documentation to help you integrate quickly.

Read the Bytescale Secure URLs Documentation to get started.

We hope Secure URLs open up new possibilities for your application — while keeping your integration fast and simple. Let us know what you think, and happy building!