Show HN: I created a URL shortener that can be entirely hosted on GitHub Pages

> Unlike many URL shorteners, this one does not need a database and can be entirely hosted on GitHub pages.

it does need a database though. it just uses someone else's database

I was always fixated with URL shorteners and always wanted to write one myself. While it would be easy to write one that works with a server, I loved the idea of hosting and running one for free.

Thus, I wrote this URL shortener which does not need a backend to work at all. It uses GitHub issues as a "database", and unlike most other URL shorteners that do not need backends, this one doesn't need a # prefixed to the alias. (i.e. short URLs look clean like this: nlsn.cf/1 instead of looking like this: nlsn.cf/#1)

I haven't had the time to work on it more but do let me know what you guys think! Thank you and hope yall enjoy it!

You could also push static HTML pages to the git root which have, e.g.,

<meta http-equiv="refresh" content="1; url='https://news.ycombinator.com/'" />

in the header.

Interesting. This could be considered as abuse of github issues though.

I made a shortener using nginx and a config file: https://statico.link

It uses a tab-delimited nginx map file as a config. To make changes, I wrote a tiny shell wrapper which opens the config in Vim, checks it in, and reloads nginx: https://statico.link/how

People frequently asked me for a list of all of the links, so I wrote a tiny server to serve them: https://github.com/statico/statico-link-list

Somebody was faster than me https://github.com/nelsontky/gh-pages-url-shortener/issues/1...

I was sure this was going to use Actions, using Issues is... More elegant I suppose.

Babel though? Packages? JavaScript? This could just be a single HTML file, surely?

3425 lines in package-lock.json for a "Minimal URL shortener"

https://github.com/nelsontky/gh-pages-url-shortener/blob/mai...

Better be ready for the malicious links. I'm the developer of https://t.ly/ link shortener. I spend most of my time adding in protection to prevent people from using the service for malicious links.

Using GH issues as DB :P I wonder how long before GitHub will notice and shut it down for abuse.

Very crafty project, I wonder if there is an awesome-github-pages repo where we could index these GitHub pages projects.

Congrats! I really love this concept for two reasons.

First I'm always fascinated by smart solutions that make use of existing free (as in beer) infrastructures to provide a service with open-source software. In this way we truly get FOSS.

Second, I really like the idea that the information on where the shortened url redirects to is publicly available. I know that solutions like bitly.com do provide a way to preview the shortend url, but I think this is just more transparent, although admittedly a little bit less obvious.

This is really cool. I think it might even be possible to improve it further so opening an issue isn't even needed.

My thinking is you could store the links and the corresponding shortened URL lookups as an element in the HTML source itself. You would have a submit input on the page. User enters the url they'd like to shorten (or is pulled from a param). The JS reads that value and then looks it up to see if it already exists in the element you created for storage. If not, it creates a hash as the shortened 'link' and adds it to a hashmap / element. Now this is the crucial part: have JS call the Github Actions API to trigger a workflow (https://docs.github.com/en/free-pro-team@latest/rest/referen...) that puts the updated hashmap (which is a payload for a custom parameter you defined for the GH Action) into a file e.g. `links.json` or even outputted directly into the HTML source. Then have the action commit this file back into the repo. Thus, the flat file in the repo acts as the storage mechanism for the links. From a UX standpoint, this is a little smoother and more cohesive (same site to input & redirect) than having to open a GH issue.

With this approach, you can still have the nlsn.cf short domain redirect as long as you pass the URL params and get them in JS from the location, which it looks like you already do. I might try whipping up a version of this tonight. Thanks for the inspiration!

Interesting, I just did http://nlsn.cf/54.

I just found a "bug" that can be abused (in chrome at very least).

URL('http:53') returns https://0.0.0.53 (it casts the int32 number to an ip address, dont' ask why). But window.location.replace behaves differently and treats it as a relative URL.

For the first time to me, the MacBook Air looks better than the MacBook Pro. No touchbar, no fan (no noise) and more than enough power. From the test I found, seems like you can max out the M1 for 7 minutes before it start throttling down.

Brilliant. Works well.

But this has a chance of not working since you are doing the redirection client-side. Some addons block 3rd party resources. Looks like you're using the github API and sending the request from the user's browser.

If you're using github pages you should just structure jekyll such that you can edit data/_links.yml instead of having thousands of users wasting compute power for github api when its not necessary

I was expecting it to be a way of taking a URL and converting it to a base64 type of format that is stored on the "url" itself and decoded by a simple web page. I have wanted to try to do this for a while, but never saw down to look for an appropriate encoding that somehow also compresses.

I helped someone design a regular URL shortener in PHP before, they're not complicated to implement with a simple MySQL (or even SQLite) database and any language you're familiar with. I have not taken a stab at writing a client-side shortener yet on the other hand.

Edit: clarifying

Bad for so many reasons (including abuse of GitHub issues, spam, and the ability to change the URL the short link points to)

If you want your own private shortener, I have a better idea:

Use GitHub Pages and create a `/1/index.html` (where 1 is the short link name) and add a “refresh” meta tag in it. Completely static and no build/JS necessary.

This could be opened up to others by combining it with issues and GitHub Actions, but who wants that?

Another better idea for a private URL shortener is hardcoding a list of URLs in a CloudFlare Worker. Much faster and with real 301 redirects.

Such a fun little hack. The killer feature is that you found a way for anyone to create a new short URL without a pull request or any changes to the original repository. Nice work.

There's a lot of useful stuff to learn from this tiny example, providing you look at it more as a learning exercise than a production enterprise solution!

OP, how does this get around CORS?

That is quite interesting. Only issue is to rely on Github Issues for it (it might get messy with too many issues opened).

I had this same ~dream of hosting a URL Shortener statically, which lead me to create URLZap. The difference is that it relies on a config file and it can be used on any code repository service https://github.com/brunoluiz/urlzap

Neat project. What were your ideas for storing the content in git version history? (i.e as files itself?)

Shameless plug for a similar project that i did few years back: A (partial) static site generator based on github issues :) https://github.com/geekodour/gitpushblog

This could be implemented on top of any collaborative tool such as Wikipedia or anywhere a user can enter some text something like a comment section. For example instead of creating Github issue every time one could just reply to an existing issue with the desired URL and have the tool redirect to it based on a unique id.

Well, I clicked this link and got disappointed immediatly. Apparently the idea is neither original new nor useful.

Then I got a little offended by myself. Information Theory has stated clearly that universal compression is impossible, and how come that I didn't recall that?

I setup YOURLS* for a client several years back, worked quite well. Was always a little concerned about privacy/potential for abuse (being self-hosted) but we never had those issues due to the limited use & exposure.

*https://yourls.org

Here's an implementation using plain javascript and a JSON file to store short-codes and target URLs: https://www.btbytes.com/posts/url-shortener.html

I would find it better if he'd add something like an auto accept pull request bot, that allows you to append a single url (with validation check + rate limiting) to a file, that will be read by the url shortener + auto deploy on new master commit. That would be truly databaseless.

It's so cool. I am using https://git.io as url shortener, and now this project makes me reconsider.

What if some of shortener domain so popular that Github takes some action? Like block or ban?

This is brilliant! Especially to distribute branded shortened URLs of the kind {mydomain}/{id} without having to maintain pretty much anything and giving the end user a chance to verify what the URL actually leads to. Thank you!

I made a URL shortener for the organization I work at using Amazon S3. I created a bucket that is hosted as a website, to which I upload empty files with the "Redirect" metadata field to indicate the destination.

At first I thought it was a true static site generator, like mine: https://github.com/nkantar/sus

Interesting take!

If you prefer Netlify: https://github.com/kentcdodds/netlify-shortener

And by sorting issues and comments by vote, also reddit.

I like mine better :P

https://github.com/wesleytodd/short

Not working now...

EDIT (After 1 minute): Looks like its working again. Wonder how such a service can go down. Was Github's server failing or DNS?

Shortened link to this discussion: https://nlsn.cf/11

I wonder whether this idea could be taken further and rely on existing redirection service. So you won't host anything.

This is a cool project to play around and do but I don't think people will use it in a practical sense

I was just thinking of this the other day, and how I wanted to try doing this without a database. Bravo!

We have too many URL shorteners already. These things accelerate link rot.

GitHub really needs to step up its CORS game.

Isn't https://archive.is better? It also archives the web pages;

This currently uses about 100KB of JavaScript (over 99KiB of polyfills, about 3KiB of actual code), loading the HTML file, then three JavaScript files, then making an API call to GitHub, then finally doing the actual redirect, by a substantially inferior JavaScript technique. Also, it doesn’t work on IE because the polyfills were insufficient.

Yes, this is an interesting technical demonstration of a concept, but it also has some rather serious problems, so that I would strongly recommend that no one actually do things this way.

----

Firstly, the size of the code: I just golfed it for fun, I think this should do for the full document (though I haven’t tested it):

  <!doctype html><meta charset=utf-8><title>Redirecting...</title><script>e=new XMLHttpRequest(),e.addEventListener("load",function(){try{if(/^https?:\/\/(?!nlsn\.cf(\/|$))/.test(e=JSON.parse(e.responseText).title))return location.replace(e)}catch(e){}location.replace("/")}),e.open("GET","https://api.github.com/repos/nelsontky/gh-pages-url-shortener-db/issues/"+location.pathname.split("/")[1]),e.send()</script>

100KB in four requests, down to 412 bytes in one request (and that 20 bytes of <meta charset=utf-8> isn’t even particularly valuable). And it restores support for IE, by using simple regular expression testing instead of `new URL(…)`, which IE never supported. As written, I believe it should work down to IE9, and older could be supported if you replaced the load event handler with an onreadystatechange incantation.

(Other general remarks on the HTML:

1. In <meta charset="utf-8" />, the trailing slash is completely ignored by the HTML parser; in fact, I reckon using trailing slashes like this is actively slightly harmful, because it misleads you into thinking it closes elements, as in XML, but it doesn’t.

2. On the script elements, type="text/javascript" is the default and thus not needed.

3. <html>, <head> and <body> wrappings can all be omitted from the source. This one is a bit more subject to taste; I know some like their source to match the parsed document tree, even down to things like writing the <tbody> out even if there is no thead or tfoot. But I myself always omit the end tags on these, and omit the start tags unless they have attributes, which in practice means I always have the <html> for its lang attribute.

)

----

Secondly, the redirection technique. There are good reasons why you should use HTTP redirects and not JavaScript location.replace for something like this:

1. If you use JavaScript, any users unable to run the JavaScript are left high and dry. This includes people like me that disable JavaScript by default (I because it makes the web so much faster and less annoying; others for privacy reasons and similar), but it would also help people on poor-quality connections, especially if the JavaScript is loaded in a different connection (which will probably not be the case here), because it’s surprisingly common for parts of pages’ resources to simply fail to load sometimes on poor-quality connections.

2. Various tooling like link checkers likewise won’t be able to work with this. As it stands, even link checkers that ran JavaScript would fail on this because you’re also using location.replace to show the “bad link” error. (Another of my pet peeves: doing a redirect to a “not found” page, rather than serving the “not found” page at the original URL with status code 404.)

3. It’s perfectly feasible for the connection to https://nlsn.cf to have succeeded, but the connection to https://api.github.com to fail. When this happens, you’re left trying to decide what to do; and location.replace("/") is a very bad solution, because you’ve now trashed the URL and I can’t even just try reloading the page to see if it works second time round. If you use HTTP redirects, everything will work perfectly in all cases, regardless of which connections succeed or fail.

4. Browsers have redirect loop detection, but you’ve opted out of that. In this thread someone pointed out simple loops and you’ve now tried to work around this by telling it “don’t redirect to the same domain”, but this really isn’t enough: you can easily have A → B → A. If this was done with HTTP redirection, the browser would twig and show an error and stop; but because half of the loop is done with location.replace, this won’t be caught. (Also, there are perfectly legitimate cases for a short URL redirecting to another short URL which redirects to a long URL, which this has now broken.)

----

A more amusing concept that occurs to me is implementing the URL shortener in a service worker, so that you can issue proper HTTP redirects, while doing it only on the client side.

Very smart use! Creative!

Not working now...

nice discovery!!

Since I am running a URL shortener service https://blanq.io, my two cents:

1. I looked at https://github.com/nelsontky/gh-pages-url-shortener/blob/mai... and it is a basic script that does nothing more than redirection. A lot of URL shorteners on the web do a lot more. Premium ones can track users and route links based on client.

2. Most of URL shortening audience is non-technical and they usually like to pay and forget about it. Hosting and running your own service is an overhead.

3. Handling traffic at scale is challenging. So, if you have a lot of hits, I would not advise spending time maintaining the service.

4. Github can kill this anytime.

That said, this is neat solution for basic needs.