Was just working on something similar this morning. As an fyi you can avoid the string replacing in the base64 string by using `.toBase64({ alphabet: "base64url" })` and `fromBase64({ alphabet: "base64url"})`.
Per the spec [0], a URL can hold at least 8,000 characters.
> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements. Note that this implies some structures and on-wire representations (for example, the request line in HTTP/1.1) will necessarily be larger in some cases.
Mainstream browsers support at least 64,000 characters [1], and Chrome supports up to 2MB [2].
I guess the surveillance industry has enough incentives to make this ever larger, so they can fit more utm-trackers, campaign-ids, referal trackers and whatnot in URLs.
It's truly insane how large typical share-URLS for content on instagram, youtube or any other large platforms are. URLs that could've been example.com/t/some-large-enough-id?time=13337 are stuffed with hundreds of characters, just to gather more data on people using these links.
> Per the spec [0], a URL can hold at least 8,000 characters.
> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
It is always worth remembering that, unless you have already ensured that the content has been rendered into a URI-safe subset of ASCII, a character and an octet are not the same thing.
I really like this from a privacy point of view. So much so that I'm thinking about adding a purely URL-storage solution as an option in my https://kraa.io editor.
I recently build a small framework to create JavaScript apps that use this kind of URL sharing and therefore don’t require a backend: https://github.com/grothkopp/lost.js
I made something similar once, specifically targetted for guitar tablature https://tabviewer.app/
To make links shorter for sharing with others, I use a shortlink service. Pasting URLs of thousands of characters long can be problematic
Think you've inadvertently found a way to provide extra tests for mobile devices.
The Crime and Punishment one consistently crashes Brave mobile for me. I assume it's the length of the URL - and seen another commentator say the same for chrome mobile (sure they both use the same codebase so likely an upstream issue).
A few weeks ago I vibe coded a guitar tab editor just because I wanted to share a quick tab in a chat group with my band. When the first prototype already worked great, I just couldn’t stop to add features so that it now even has mouseover chord diagrams and copy and paste.
The sharing works just like here, by encoding the tab itself in the url.
In Firefox, https://textarea.my shows up as as a completely static non-actionable white page. Just white, with default cursor. No errors on the console.
Thanks for sharing! I tried a similar content-in-url approach for a family grocery list app but I couldn't get the url that short. (It worked but it was a bit cumbersome sharing over Whatsapp.) Will see what I can learn from this!
I created a similar app just 2 days ago targeting Whatsapp (https://linqshare.com) . Context: In my locality, EA, we normally have Whatsapp groups raising funds for whatever reason; for every content edit, the admin has to copy-edit-paste updated content(which contains name and amount) to the group. This small app intends to provide a table that's easy to convey this info. App stores content in the url but a preview image (needed for Whatsapp share) is stored at R2. Let me know if you want the source code running at Cloudflare.
love it, funny enough, I had similar idea pop into my head some weeks ago, just to be able to store quick notes and favorite them in my browser for later
I like these kinds of projects, but adding a file export/import is inevitable. It's less about the limits of a URL and more about practicality.
I also have no way to confirm that URLs aren't logged server side, so I'd never trust the claim about "no tracking". That's why these projects also end up self-hosted.
Typos and URL mangles are common though, and I'd still have no way to confirm if it got logged in that case. It's out of scope for anything in the github source, and instead depends on the server hosting the page. I know this isn't meant to be super secure, but it's still worth a mention.
Typos aren't making the hash part turn into something else. Like your parent comment explained to you, the hash part is not sent to the server. If you go out of your way to mangle the URL then of course a mangled URL without hash will likely get logged to the server. But I'm not sure how one would manage to go so much out of the way that they mangle the URL in a way that removes the hash.
I needed a way to share a link to a map, with drawings and the ability for the receiver to see their own location on the map.
Annotated screenshots solves the first but not the second.
Vibe engineered this, with many of the same ideas as OP.
Took an evening. Just in time apps for one specific use case is a thing.
And because it's so cheap to make and can be hosted cheaply with no backend, it can be given away for free.
https://nyman.re/mapdraw/#l=60.172108%2C24.941458&z=16&d=LU8...
While I'm all for vibe coding as appropriate, there's a lot of humor to be found it calling it engineering. :D
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements. Note that this implies some structures and on-wire representations (for example, the request line in HTTP/1.1) will necessarily be larger in some cases.
Mainstream browsers support at least 64,000 characters [1], and Chrome supports up to 2MB [2].
[0]: https://www.rfc-editor.org/rfc/rfc9110#section-4.1-5
[1]: https://stackoverflow.com/a/417184/
[2]: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
Here is the Crime and Punishment by Fyodor Dostoevsky:
- https://medv.io/goto/crime-and-punishment-by-fyodor-dostoevs...
https://github.com/swiftlang/swift-corelibs-foundation/blob/...
It's truly insane how large typical share-URLS for content on instagram, youtube or any other large platforms are. URLs that could've been example.com/t/some-large-enough-id?time=13337 are stuffed with hundreds of characters, just to gather more data on people using these links.
> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
It is always worth remembering that, unless you have already ensured that the content has been rendered into a URI-safe subset of ASCII, a character and an octet are not the same thing.
https://github.com/planbnet/guitartabs
The Crime and Punishment one consistently crashes Brave mobile for me. I assume it's the length of the URL - and seen another commentator say the same for chrome mobile (sure they both use the same codebase so likely an upstream issue).
[1]: https://davidlowryduda.com/mathshare/
I built Ponder in the same vein. It, however, has 10 files. I did not use the URL, did not have double the fun, and now I’m sad.
https://github.com/codazoda/ponder
- https://textarea.my/#TYuxDcIwEEWpmeKUCiSIJQoKU0KFRBUWOGwnWDi...
The sharing works just like here, by encoding the tab itself in the url.
https://github.com/planbnet/guitartabs
https://sqlscope.netlify.app/
Safari 15.6.1: Unhandled Promise Rejection: ReferenceError: Can't find variable: CompressionStream
https://gist.github.com/smcllns/8b727361ce4cf55cbc017faaefbb...
Now if you bootstrap the app code into the url too then you can have a minimal kernel to run any machine in url.
Then you can also make a Quine somehow.
--edit-- test link: https://linqshare.com/#eJxtkM9KxDAQxl-lzLmHrv8Ova3IHlz04BY8F...
Half a megabyte for a URL. That certainly is a thing.
I also have no way to confirm that URLs aren't logged server side, so I'd never trust the claim about "no tracking". That's why these projects also end up self-hosted.