102% yeah.

This specific URL has a long hex component for the commit hash.

We might be able to get that size down by encoding the hex string at the end into numbers. I'm working toward this in radix_coder.js[1]. I'll open an issue[2]. Thanks!

In tests of strings not URIs I got 68% of original for digit strings, and 90% of original for base36 strings, after encoding as numbers then into base64.

More generally I see rates of 70% to 90% for URIs that have a mix of words and numbers. And more than 100% for strings with lots of identifiers.

Eg:

   https://www.citylab.com/housing/2017/05/the-new-suburban-crisis/521709/?utm_source=SFTwitter

Is 89%

And

  http://www.saveur.com/chinatown-produce-prices

Is 70%

While

  https://www.gov.uk/search?q=Grants&filter_organisations%5B%5D=hm-treasury

75%

OK is not an informative commit message. Thanks for the prod. I'll open an issue.

Issue: https://github.com/dosaygo-coder-0/urizip/issues/5

And thanks for commenting! If you any ideas about how to improve the compression please submit a PR!

[1] https://github.com/dosaygo-coder-0/urizip/blob/master/radix_...

[2] https://github.com/dosaygo-coder-0/urizip/issues/6

It isn't great.... it's just ok

I want to point out that yes, even tho it's longer than the URI by 2% , it is shorter than the Base64 encoding of the URI by 24%

For high entropy URIs with long identifier sections, this is common. While we may exceed the length of the original URI, we are almost always shorter than the Base64 version.

And this is just the first iteration of this algorithm. I think we can do better when we introduce some new ideas that people have suggested and are already in the works!

Thanks!