Here you’ll find some extra Shlink features, which are not as evident, but you might still want to take advantage of.
This document also tries to clarify why some of these features work the way they do.
- Short URL title
- Device-specific redirects
- Query params forwarding
- Extra path forwarding
- Multi-segment custom slugs
- Short URLs trailing slash
- Short URLs mode
- QR Codes
- Bot detection
- Email tracking
- Service healthiness
Shlink v2.6.0 introduces the ability to optionally set a
title for every short URL.
The title can be provided, but it’s also possible to enable title auto-resolution. When that’s enabled, and the title is not provided, Shlink will try to infer the title by calling the long URL and picking the value inside the
<title /> tag.
The title can be changed later on. If the long URL is changed, it will also try to auto-resolve the new title, unless the title was originally provided during creation.
Shlink 3.5.0 has introduced the possibility to dynamically redirect to different long URLs depending on the device used by the visitor.
This way, Shlink can use the
User-Agent header to determine if the visitor is coming from an
desktop device, and redirect to a long URL specifically set for the appropriate device.
If none was set for resolved device type, or it was not possible to accurately determine the device type, then a redirect to the regular long URL will happen.
It is possible to have more granular device types in the future, like android table, iPad, Windows, Mac, etc.
Feel free to open a feature request if you find a missing but useful device type sub-group.
By default, Shlink automatically forwards to the long URL all query params originally sent to the short URL.
For example, if you have a
https://exam.ple/abc123 URL that points to
https://www.google.com, when users visit
https://exam.ple/abc123?foo=bar, they will get redirected to
If for any reason the long URL already had query params, they will be merged with the ones sent to the short URL. In case of conflict, the value sent with the short URL will take precedence over the original URL one.
For example, if
https://exam.ple/abc123 points to
https://www.google.com?foo=bar, when users visit
https://exam.ple/abc123?foo=overwritten&another=param, they will get redirected to
Starting with Shlink v2.9.0, this behavior can be overwritten on every individual short URL, allowing to disable the query params forwarding if desired.
Starting with Shlink 2.8.0, Shlink can match short URLs as soon as the visited URL starts with an existing short code.
When this happens, Shlink will append the rest of the path to the long URL before redirection.
For example, if you have a
https://exam.ple/abc123 URL that points to
https://www.twitter.com, you can make Shlink capture visits to
https://exam.ple/abc123/shlinkio and redirect to
When this happens, Shlink will track the visit as usual.
This behavior needs to be actively opted in, as it’s disabled by default.
Shlink 3.2.0 introduced the ability to create short URLs with multi-segment custom slugs.
That means that you can provide multiple parts separated by slashes as the custom slug, ending with something like
This feature has some considerations though:
- When this is enabled, any URL will match a potential short URL. That means any future orphan visit will have either
invalid_short_urltypes, but never
- Because of previous point, this is considered a breaking change, and therefore, it’s disabled by default, and you have to actively opt in.
- If Extra path forwarding is also enabled, there’s always a chance of conflict. If you have both
https://exam.ple/foo/bar, when the second one is visited, it will match the first one, and the
/barpart will be forwarded to the long URL.
This means that, while the feature is enabled, if you create the short URL
https://examp.le/foo and a user ends up visiting
https://examp.le/foo/, the visit will be properly captured and the user will be redirected.
In older versions of Shlink or when this is not enabled, visiting a short URL with trailing slash results in a 404.
If you want to support trailing slashes in any route known by Shlink and not only short URLs, you can configure the web server in front of Shlink to strip trailing slashes before calling it:
- Nginx: https://ubiq.co/tech-blog/remove-trailing-slash-in-nginx/
- Apache: https://ubiq.co/tech-blog/how-to-remove-trailing-slash-in-apache/
- Caddy: https://caddy.community/t/efficient-remove-trailing-slash-redirect/3289
By default, Shlink always matches short URLs in a
strict mode, meaning it does a case-sensitive check when trying to determine which short URL has been visited.
This effectively means
https://s.test/AAABBB are considered different URLs by Shlink.
Starting with Shlink v3.5.0, you can customize this behavior, and make Shlink consider those two URLs to be the same.
loose mode has a couple of considerations:
- Shlink will no longer generate short codes with uppercase letters. Only lowercase and numbers will be taken into consideration.
- When providing a custom slug, Shlink will lowercase it, so if there’s a URL with
AaaBbbis provided, it will throw an error saying it already exists.
- On existing Shlink instances, already existing short URLs will not be changed in any way. If “conflicting” URLs already exist, they have to be fixed manually.
- Loosely checks are done only for “public” URLs (short URLs, QR codes and email tracking). REST API endpoints do strict matches no matter what.
Shlink comes with built-in support to generate QR codes for any short URL.
Getting a QR code URL is as simple as appending
/qr-code to any short URL. So if your short URL is
https://exam.ple/abc123, the URL which returns the binary QR code image is
The image supports certain level of customization via query params:
size: It determines the width/height in pixels. Default value is 300 and accepts values from 50 to 1000.
margin(since v2.6.0) : The space in pixels between the QR code itself and the border of the image. Default value is 0 and accepts positive numbers.
format(since v2.4.0) : Can be
svg. Default values is
errorCorrection(since v2.8.0) : Can be
H(High). Default value is
L. Learn more.
roundBlockSize(since v2.10.0) : Can be
false. Tells if the block size should be rounded, making the QR code more readable, but potentially adding some extra margin as a side effect.
See the “endpoint” docs for more information.
Take into consideration that the total size of the image will be determined by the size + the margin times two. So, if the size is 500 and the margin is 20, the resulting image will be 540x540 pixels.
Starting with v2.7.0, Shlink can now detect visits from potential bots or crawlers, based on the visitor’s
Of course, there’s never a 100% accuracy here, hence the potential.
All the endpoints serving visits will include the
potentialBot flag with values
false, and they also allow excluding potential bots from the result set.
Shlink can track how many times an email has been opened, by taking advantage of its URL tracking capabilities.
You can track emails with any existing short URL, or create a new one pointing to a dummy long URL (the redirect itself is not important for this use case).
Then, by appending
/track to the short URL, you will have a new URL (for example,
https://example.com/abc123/track) that resolves to a 1px transparent image. Add it to any email you want to track.
The image is effectively invisible, but every time the email is opened and the image is loaded, Shlink will count one visit.
In some situations you may want to know if your Shlink instance is healthy. Reasons might include monitoring, but also letting orchestrators know if one specific instance can respond to requests.
Shlink exposes a
/rest/health endpoint, which does not require authentication, and can be used for this purpose.
You can find more information in the API docs.