How to store your app's entire state in the url

App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding.

As one comparison, this is Google Finance encoding stock chart parameters:

  https://www.google.com/finance/quote/F:NYSE?window=5Y

Versus Yahoo! Finance doing the same:

  https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZVdpZHRoIjo0LjM0ODY1OTAwMzgzMTQxNzUsImZsaXBwZWQiOmZhbHNlLCJ2b2x1bWVVbmRlcmxheSI6dHJ1ZSwiYWRqIjp0cnVlLCJjcm9zc2hhaXIiOnRydWUsImNoYXJ0VHlwZSI6ImxpbmUiLCJleHRlbmRlZCI6ZmFsc2UsIm1hcmtldFNlc3Npb25zIjp7fSwiYWdncmVnYXRpb25UeXBlIjoib2hsYyIsImNoYXJ0U2NhbGUiOiJsaW5lYXIiLCJzdHVkaWVzIjp7IuKAjHZvbCB1bmRy4oCMIjp7InR5cGUiOiJ2b2wgdW5kciIsImlucHV0cyI6eyJpZCI6IuKAjHZvbCB1bmRy4oCMIiwiZGlzcGxheSI6IuKAjHZvbCB1bmRy4oCMIn0sIm91dHB1dHMiOnsiVXAgVm9sdW1lIjoiIzAwYjA2MSIsIkRvd24gVm9sdW1lIjoiI2ZmMzMzYSJ9LCJwYW5lbCI6ImNoYXJ0IiwicGFyYW1ldGVycyI6eyJ3aWR0aEZhY3RvciI6MC40NSwiY2hhcnROYW1lIjoiY2hhcnQifX19LCJwYW5lbHMiOnsiY2hhcnQiOnsicGVyY2VudCI6MSwiZGlzcGxheSI6IkYiLCJjaGFydE5hbWUiOiJjaGFydCIsImluZGV4IjowLCJ5QXhpcyI6eyJuYW1lIjoiY2hhcnQiLCJwb3NpdGlvbiI6bnVsbH0sInlheGlzTEhTIjpbXSwieWF4aXNSSFMiOlsiY2hhcnQiLCLigIx2b2wgdW5kcuKAjCJdfX0sInNldFNwYW4iOnsibXVsdGlwbGllciI6NSwiYmFzZSI6InllYXIiLCJwZXJpb2RpY2l0eSI6eyJwZXJpb2QiOjEsImludGVydmFsIjoid2VlayJ9fSwibGluZVdpZHRoIjoyLCJzdHJpcGVkQmFja2dyb3VuZCI6dHJ1ZSwiZXZlbnRzIjp0cnVlLCJjb2xvciI6IiMwMDgxZjIiLCJzdHJpcGVkQmFja2dyb3VkIjp0cnVlLCJldmVudE1hcCI6eyJjb3Jwb3JhdGUiOnsiZGl2cyI6dHJ1ZSwic3BsaXRzIjp0cnVlfSwic2lnRGV2Ijp7fX0sImN1c3RvbVJhbmdlIjpudWxsLCJzeW1ib2xzIjpbeyJzeW1ib2wiOiJGIiwic3ltYm9sT2JqZWN0Ijp7InN5bWJvbCI6IkYiLCJxdW90ZVR5cGUiOiJFUVVJVFkiLCJleGNoYW5nZVRpbWVab25lIjoiQW1lcmljYS9OZXdfWW9yayJ9LCJwZXJpb2RpY2l0eSI6MSwiaW50ZXJ2YWwiOiJ3ZWVrIiwidGltZVVuaXQiOm51bGwsInNldFNwYW4iOnsibXVsdGlwbGllciI6NSwiYmFzZSI6InllYXIiLCJwZXJpb2RpY2l0eSI6eyJwZXJpb2QiOjEsImludGVydmFsIjoid2VlayJ9fX1dfQ--

In both examples, the only custom parameter is setting the time window to 5 years.

This is quickly becoming a standard in apps and it really shouldnt be handrolled since its such a common requirement and easy to get wrong (between serializing/deserializing/unsetting states). In Svelte it is now as easy as using a store: https://github.com/paoloricciuti/sveltekit-search-params

in general i've been forming a thesis [0] that there is a webapp hierarchy of state that goes something like:

1. component state (ephemeral, lasts component lifecycle)

2. temp app state (in-memory, lasts the session)

3. durable app state (persistent, whether localstorage or indexeddb or whatever)

4. sharable app state (url)

5. individual user data (private)

6. team user data (shared)

7. global data (public)

and CRUD for all these states should be as easy to step down/up as much as possible with minimal api changes as possible (probably a hard boundary between 4/5 for authz). this makes feature development go a lot faster as you lower the cost of figuring out the right level of abstraction for a feature

0: relatedly, see The 5 Types of React Application State, another post that did well on HN https://twitter.com/swyx/status/1351028248759726088

btw my personal site makes fun use of it -> any 404 page takes the 404'ed slug and offers it as a URL param that fills out the search bar for you to find the link that was broken, see https://www.swyx.io/learn%20in%20public

This is pretty common and has a bunch of advantages, like the fact you can link to and bookmark a particular state.

Also, if you are careful you get undo and redo for free with the browser's back button doing all the work for you.

The disadvantages are that your representation of internal state becomes part of the interface - if you ever change your app you need to deal with versioning the state so your new version can transparently handle the old state format.

If your app has a server component that acts on this state, be super careful about acting on it and treat it as you would any other input under user control.

If you app is completely client side, consider storing the state in the #fragment section of the URL. This never gets sent to the server. An example from my own site [0] - see how the fragment part of the URL changes as you select different topics.

There are also limits on just how much you can cram into a URL but with care you can shove a lot of state.

[0] https://sheep.horse/tagcloud.html#computing

A better idea is to use the URI fragment (the string after the # sign). It has the advantage of not having a size limit, and not needing to be sent all to the backend during the request. `window.location.hash` is your friend.

We wrote a library for storing application state in the URL. Its novel feature is using fragment query, which prevents the information from being sent to the server.

https://github.com/Cyphrme/URLFormJS

I would love to see it get more use.

Here's a small demo: https://cyphrme.github.io/URLFormJS/#?first_name=Bob&last_na...

See my other comment on this page for some other examples of its use.

I did this for an Othello game back in the 90's. The state was encoded in the URL along with the players move. It seemed weird to encode a slightly different URL for every move the player might click, but that also meant squares that were not legal moves didn't get a URL. And that meant the mouse pointer would change when you hovered over a valid square! Another trick was to return the updated board state, but also include an automatic reload after a few seconds with the computers next move already determined. This made it look like "thinking" was going on when in fact it was already decided when the board updated on players move ;-) This was all in a CGI script. As others have pointed out, it also supported "undo" via the back button. Fun.

Last November I had covid and during that time I wrote a little pastebin that runs in the browser, compresses the paste data with Brotli, and puts it in the URL. It has line numbers, file naming, and syntax highlighting so it's feature complete for my own use. Here's a demo, but beware, the URLs are loooong: https://nicd.gitlab.io/t/#NhfW?Qm3F?6-&22c&CQZXuP+Aej5OXzXk7...

I find it interesting to sometimes play around with the pasted data just to see how it compresses. Sometimes adding a character or two may cut several characters from the URL length!

I love stuff like this. Around 2008 or so I was working on a Java game for the T-Mobile Sidekick (aka hiptop). The platform let you register url scheme handlers so I registered "drod" (the game was a from-scratch port of Deadly Rooms of Death, a classic shareware game). Since the game was a 16x16 grid-based game with 3 layers, it was super efficient at expressing levels, including monsters and locks and keys, with just a limited number of bits. On my website I had "DLC" in the form of drod://[base64 encoded level here]. It always filled me with joy that users already downloaded the levels when they navigated to the website. Clicking the link just opened the game with the data they already had on their device.

Isn't this also how old school games (I've seen it as late as the NES I think) did allow you to save progress, you'd get a short string as your "save" and could just enter it to restart the game in the same state later. I love that it offers essentially unlimited "saves"

In React you normally create local ephemeral state like this:

    const [myState, setMyState] = useState(null);

I've created at least 3 libraries that follow that same pattern, but instead of ephemeral the state is saved somewhere:

    // ?firstname=
    const [firstName, setFirstName] = useQuery('firstname');

    // localStorage
    const [name, setName] = useStorage('name');

    // global state (that can be connected to other places)
    const [user, setUser] = useStore('user');

Made this thing in 2010. I can't remember if I saw the trick being used in another website before or not... https://mrdoob.com/projects/voxels/#A/bnciaTraheakhacTSiahfa...

Hey all, I made this post to show a technique that I'm using in my keyboard-centric flowchart editor [0]. I really love urls, and the power that they hold, and would love to see more apps implement little hacks like this.

Also, another shout out to mermaidjs and flowchart.fun for also implementing similar url-based sharing.

[0] https://www.knotend.com

I had to add compression into Mermaid live editor's URL state as the length limit was exceeded with big diagrams.

Wrote this SerDe which can be extended with better algorithms in the future. https://github.com/mermaid-js/mermaid-live-editor/blob/devel...

Eg: https://mermaid.live/edit#pako:eNo9kUGTnCAQhf8K1adNlesoqKiHV...

I did something similar, but compressed with pako to make the URL as short as possible: https://www.pokerregion.com/?r=Y2RwYBBgYGFkcGAQYGBhZHBgEGBgY...

Here is the compression code: https://gist.github.com/kissgyorgy/39623a7d0ba2f6faafb464b72...

I used the properties of my data structure (multiple cards represented in a byte as bits) to represent the same data on less bytes (to avoid compressing JSON with unnecessary characters)

There is a max length to URLs after which it is all wild west based on the browser implementation.

See: https://stackoverflow.com/a/417184

Great for complex apps in the browser and sharing complex save states!

Bad for ordinary, mundane web applications and sharable URLs!

Like, great for a musical step sequencer in the browser, bad for a website or HTTP service

OTOH, app state on websites of commercial service prodivders might be best represented by a JSON blob anyway.

In something like a checkout process or form submit, of course this doesn't matter much.

But I prefer human-readable URLs wherever possible.

And I implemented a similar pattern once, too.

It's a very interesting approach in intself.

Relevant POJO state tends to be small enough but long lists or resourcrs in a URL are not supported by most servers and not advisable.

Just do not. That or alternatively a hidden field is how asp.net WebForms did it state management 20 years ago. Worst possible idea ever.

Good for small scale unimportant external state management but not for your everyday web app.

I tried to do that at first with https://textshader.com because the whole site is client-side and I didn't want to bother with a backend. It didn't really work because the state is unbounded in size, so instead I just chuck it on GitHub gists and then point to the gists. It means I don't have to store any data myself and there's zero recurring costs outside of the domain name... but if the site ever got popular I'd probably have to figure something else out.

On a related note …

If you don’t want to store anything on the server, why serve the static JS and HTML? You can embed them in the URL also.

In that cass the URL just becomes a local file.

You should store the file locally, along with all the data it embeds.

Or you can store the files on a CDN at the edge. The problem with the latter is that people can abuse the storage.

Really, the Web needs to be overhauled to have a topology more like a DHT, where you only have peering agreements with a few peers, and they cache the content temporarily when it is requested a lot. So no centralized servers at all.

Vuejs Playground does this. This is the url for the default tamplate:

https://sfc.vuejs.org/#eNo9j71uwzAMhF+F5eIWqCV0NZQA3foGXbikj...

Worth to note that it actually should use the base62 https://en.wikipedia.org/wiki/Base62

It’s the same as base64 but w/o "+" and "?" symbols.

> Another great benefit is that these urls can be embedded. That means the user can put their graph on any ewb page that supports embedding. I see people typically do this with wikis like Notion, which means you can share with a team

This is so valuable that it can't be overstated. Being able to store the raw data in a link WITH the visual representation, you'll never struggle trying to find out who has the latest version.

This is exactly how Shel Kaphan (first eng @ Amazon) handled the state of a shopping cart in the mid 90s. Here is him discussing some of the pitfalls: https://lists.w3.org/Archives/Public/www-talk/1995NovDec/020...

About 6 years ago I had to do this on a project. We had charts with a lot of options and we wanted them to be bookmarkable and shared between colleagues. We started with base64, soon moved to a custom encoding with version support https://github.com/ananthakumaran/u

I built a quick/wip payroll validator [0] that can read state (i.e. payroll details) from the URL.

The purpose in this case was to generate a QR code, the idea is this can be included in physical payslips. Then the numbers behind the calculations (tax deductions) can be validated, broken down, and understood. I'm developing more tools to these ends, via my overarching project calculang, a language for calculations [1].

I also have a loan/repayment validator [2] but haven't added this QR code feature yet.

Bank letters e.g. "Interest rates are rising and now we want 100e more per month, every month" could use a QR code to an independent validator or to see the workings behind the 100 calculation.

Not using this in the real world now and there are security considerations to keep in mind, but reading state from a URL facilitates the usecase: QR codes that link physical numbers to their calculation and model.

Implementation of payroll calculator is an Observable notebook and thankfully it neatly supports all my strict requirements as demo of this.

[0] https://observablehq.com/@declann/payroll-playground-ireland...

+Feature tweet: https://twitter.com/calculang/status/1608183731533107206

[1] https://github.com/calculang/calculang

[2] https://observablehq.com/@declann/loan-validator-dev

What is old is new again.

Back before websites were "Apps", you could often do exactly this (Including Authentication!) right from the url.

Am I alone in thinking it's ridiculous for an editor action to push/pop state in browser history to allow undo/redo? Surely this leads to substantial browser history pollution?

As long as your users are reasonably tech-saavy this is ok. But long URLs can be problematic when sent in email for many possible reasons, such as the email client wrapping the URL and then creating a link out of just part of the original URL. The user sometimes doesn't realize this and gets unpredictable results when trying to use the URL they "saved" in the email.

Perhaps instead, assuming the user is online, hash the json state data, then send the json+hash to the server and update the URL to URL?hash. Then the user has a much shorter URL, and the server can lookup the json state from the provided hash to resume the app at that state. As a bonus you then have versions of the data over time (either posted automatically in the background or on-demand when the user clicks Save).

This is a useful idea when you've got complex nested state. The problem is changing any particular part of the state is non-trivial. I ended up making `friendly-serializer`[0] to "make objects more accessible in urls."

The idea is that instead of a base64 string, you get something that is much easier to edit in the url bar:

> name=John%20Doe&age=42&address.street=123%20Main%20Street&address.city=Anytown&address.state=CA&address.phoneNumbers.0=123-456-7890&address.phoneNumbers.1=234-567-8901

There's a similar npm project to [0] that I discovered after I'd published this, but I don't recall the name. PRs welcome.

[0] https://www.npmjs.com/package/friendly-serializer

I saw a $12 million app have to be essentially rewritten (at a bank)

The “genius dev lead who went to Princeton” kept pushing that they went to Princeton so people stopped arguing against it

Tried to do this securely and got pwned in the very first demo

Shameless plug for bashfill - a fun little drawing program for making art for bash stdout: https://max.io/bash.html?zip=eDE1eTF4MjRlMXgzeTF4MzB5MXg1ZTF...

...made in 2013 :) Here's the js that runs it: https://max.io/bash.js

This reminds me of ASP.Net's viewstate feature, tbh.

This brings to mind the concept of continuation found in Seaside Smalltalk.

https://www.seaside.st

It’s actually difficult to do this in the UX.

Suppose that you have a hierarchy that was opened. Do you want to store all the hierarchy breadcrumbs in case you hit refresh, and reload all of them?

Furthermore, what about URLs to initiate an action from a particular context? If you refresh what should it show? It should show a dialog / lightbox above the page, showing the form / interface for filling out before taking this action.

This technique goes back to the late 90s where Apple WebObjects (owned by NeXT at the time) pioneered this approach in their web framework.

https://en.wikipedia.org/wiki/WebObjects

Was quite revolutionary at the time and it also included the first (or one of the very earliest at least) SQL ORMs.

This is the way. Except I would never encode the data—just store state in plain text. That way you can edit urls by hand in a pinch (comes up a lot, actually). And more trustworthy and you can be sure you take your data with you.

I do this in all my apps. https://ohayo.computer/, https://simoji.pub/, https://try.scroll.pub/, https://jtree.treenotation.org/designer/ etc.

At one point I also made a tiny lib to make it easier:

https://breckyunits.com/patch/

I imagine I'm not the first one to think of this, but a little while back I wrote a toy pastebin-like webpage that stored the code being rendered directly in the URL (with base64 and gzip compression to make it a bit smaller, although it still was quite large by usual standards). My thinking was that rather than having a centralized app for this publicly available, making a small page that could be statically hosted would make it easy for people or organizations to host their own page with whatever security they need (e.g. behind a firewall or VPN) and then the links could be shared privately on Slack or whatever without a need to add functionality for determining who should have access or how long to keep the code snippet around and instead just piggyback off of the privacy of whatever channel/DM they sent it across and how long the Slack instance is configured to retain history.

When I first came up with this idea, I was going to write some sort of server backend rather than just doing everything in the frontend, but once I started actually working on it, I realized that it wouldn't really add any value and it would make it a bit more annoying for people to self-host. Since then, I've wondered a bit how viable "static pages with state in the URL that can be easily self-hosted" would be as an alternative to a desktop GUI or Electron app for more technical users. One of the nicest parts of this approach to me is that I was able to make in only a few hours one evening despite knowing only the basics of webdev from maybe 8-10 years ago and next to nothing about programming GUIs in general. This makes me think that it wouldn't be too hard for people to fork and modify it to their own liking (e.g. changing the hard-coded style settings for rendering the code snippets), so there could be potential for an ecosystem to grow organically around something like this.

In case anyone is curious to take a look: https://gitlab.com/saghm/pastml/

Here's the non-psuedo code equivalent that can leverage the CompressionStream API rather than using a browserified-gzip-library (eg pako): https://github.com/GoogleChrome/lighthouse/blob/437eb4d757c5...

We use it in Lighthouse for the exact same purpose, a URL #hash full of state. We found that modern browsers support 10mb of data in the hash. https://github.com/GoogleChrome/lighthouse/pull/12509#discus...

As usual when I see this sort of thing, I have questions around the security needs of the application. Storing all of this information on the client means that the client has to be trusted to not mess with all of this state. If it's important, it needs to be stored and checked server-side.

Shameless plug: I made a library to encode any json as query/hash params in a human readable manner adhering to url friendly characters.

https://github.com/recurrency/urltron

Perfect use case for storing page state in url.

I'm sorta debating the merits of various methods like this because there's something I want to "Show HN" which involves browser-based analysis of CSV files... but the way I built it for myself, I just run it on a Node server that parses the file once and stores it as json and serves it when you reopen a project. So now I want to bundle the CSV/json with then project file. But putting it all in a base64 url seems a little crazy when saving/retrieving gzip files from the local filesystem is just as good an option. I think this is interesting as something to consider for shared projects, but probably not ideal if the main goal is to have everything run locally anyway.

The Typescript Playground (https://www.typescriptlang.org/play) does something similar, it gzips the contents of your code and puts it in the URL. Pretty sweet!

Only about 20 years late: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

Web servers and http enabled services can limit the length of headers and url. While this can be done it runs the risk of having surprises when unknown limits are encountered. Most of these limits are buried deep in docs, not easily visible.

This is all fun and games until the junior dev edits the code to store the user's search history in that obfuscated appState object. The users end up sharing their URLs in public and unknowingly leaking some very private data.

Something to be careful about here is that browsers/proxies/etc have arbitrary length limits on URLs, and they can vary by quite a lot

We did this once with a web-based REPL, where you could click a button to copy a link to something you'd previously eval'd and then send that to someone else and their buffer would be preloaded with it. It was super nifty, until someone tried it with a buffer that was a few hundred lines long and at least one browser just said "nope". It sounds like OP is doing some smart stuff to minimize URL length, which should help, but there's still a limit somewhere

I did something similar using Racket's (nee PLT scheme) web programming module ( https://www2.ccs.neu.edu/racket/pubs/hosc07-sk-mf.pdf ) back with an app that got on slashdot -- https://github.com/holdenk/web2.0collage

The theory was wonderful (yay! stateless load balancer etc.) but in practice browsers at the time were less than happy with trying to store that much state in the URL.

I love this. My website tenor.cards has been backend-free for a while thanks to the URLs. https://tenor.cards/design_card/?p=Rm9yJTIwdGV4dCUyMHRoYXQlM...

I didn't even know about window location hash, which I just learned from the other comments. Thank y'all.

I did something similar in a simple whiteboarding app that I made a while back:

https://github.com/jncraton/box-line-text

The data representation could probably improve in terms of readability, but I'm happy with the way it provides a concise encoding while still including the text from the document directly:

https://box-line-text.netlify.app/#;c2121Hello;5321;c1341Hac...!

Note that this could easily break or get messy as you make changes to your app. Consider either some kind of versioning indicator, or be very careful to only add fields, never changing them.

Another way to generate potentially shorter base64 strings is to use something like Python's `struct` to store packed binary data, and then base64 encode that. Better yet, if that data payload can be generated server-side, you can also sign that data payload, which allows you to statelessly verify the data payload itself.

(cf. https://docs.python.org/3/library/struct.html)

This is an interesting approach. Should help mitigate the URL max length for larger states.

However as some people have pointed out it comes with a few caveats

- The URL is unreadable for humans

- You possibly end up storing things in the URL you did not intend

- For smaller data sets the URL actually becomes larger than the URL params equivalent

- You end up having to deal with version issues, possibly even URL string migrations as the code evolves

I'm sure there still are use cases where this makes sense, but for most applications this ends up being overly complex

Congratulations, you've implemented ViewState from aspx.

Lots of sites do this. Lately for me there's

https://www.typescriptlang.org/play

I'm mixed on it. It means it's mostly useless for having your own list of creations because you have to manually store the URLs (PITA) and you need to store them somewhere accessible if you want to repo the UX of the site actually storing them where you can more easily access them from anywhere.

Also this:

https://goog.space/?data=eyJ0eXBlIjoidGV4dCIsInZhbHVlIjoiIyB...

This is a handy trick that I've used on multiple occasions. However, it may not work on some corporate networks that filter URLs with more than a certain number of characters (I've encountered limits of 2048 and 4096 characters).

The rationale being that long URLs are often suspicious and could potentially be used for SQL injection or path traversal attacks. Whether or not this is a good heuristic is left as an exercise to the reader.

I recall this technique being used in 1999. It doesn't work well with caching proxies which key off the URL, using a Cookie header is cleaner and simpler.

Limited in size as URLs encounter size limits:

https://stackoverflow.com/a/417184/768795

I wouldn't consider state in the URL fully general, as data can easily exceed that for many apps; but it's a useable technique where it fits.

Meaningful individual parameters are preferable, but similar size limits apply either way.

I always like this when the url is always copyable, but in our app, the state can get quite large. We started with base64 encoded gzip of json.stringified app state but just gets quite long. Arguably it could be reduced a little bit, but would still be hundreds-thousands of chars routinely, so we switched to using a little URL shortening service that we wrote on aws lambda+dynamodb

I do like the approach and when it works great thats fantastic - please be careful of this as an attack vector.

I know of at least one bank where this was exploited, because people see the base url, assume safe, and can't read the embedded escape / javascript in the longer part. Especially when the link is zipped into a little clickable thing and you can't see the URL at all.

Depending on how repeative the object keys are, you maybe able to save quite some spaces with compress-json [1].

Since the OP is using lz-string to do compression, I suppose the data should be repetitive.

[1] https://www.npmjs.com/package/compress-json

We are testing this on a map[0], it's fun. When tweeting the link, the tweet and its state is added to the map. Also, map stories are possible through Twitter threads. We just implemented a draw function and are working on an implementation for external geojsons.

[0] https://map.decarbnow.space

Hah, I came up with the same thing for https://fivethreeone.app/calculator .

The reason I did the compression (using pako as well) was that without it the URL was too long to show a preview on iMessage. I also compress the state manually myself which saved a bunch of bytes too.

This has taken off in the Vue community w/ https://sfc.vuejs.org/ and https://uno.antfu.me/play/ and they use the fragment so it doesn't get sent to the HTTP server

Neat. I did this for a very basic react ratio calculator I built. My state was so basic and small, it felt fine for a toy project. Certainly a practice I would scrutinize in a production application, but it could be useful.

https://locofocos.com/anything-ratio-calc

While this is great for being able to send anyone a URL to a stateful page without needing a backend database, keep in mind browsers have URL length limits and they vary by browser. Compressing as mentioned in the article can help but still you want to know when you're going to go over and figure out a plan for dealing with that.

I built a tic tac toe game for my daughter a while a go that stores the game state in the URL as a proof of a similar concept. https://letter-press.netlify.app/ttt/

IIRC some base64 characters need to go thru urlEncode

https://stackoverflow.com/questions/1374753/passing-base64-e...

Shinylive, which lets you create and share data science apps, takes this approach: https://shiny.rstudio.com/py/docs/shinylive.html

A few years ago, I worked on an app where some of the state was kept in the session and some was on the url as GET params. We ran into an issue where some browsers would only accept urls that were less than 1024 chars long. Is that still an issue today?

This is fine for f its public information and if thats fine then why not just add a param with a url encoded json string. Would this make the url shorter or longer? I think shorter. So why base64encode?

Just wondering never created an entire app around this idea

I too obsess over shorter URLs but I do love the idea that the whole state is just a URL. From the comments, use good enough defaults and URL shorteners where necessary, and it's a brilliant design for a free-tier application.

I did the same for https://markdowntable.jose.gr

As some comments suggest, I will move the data from the query string to the URI fragment to avoid the length limitation.

Hmmmmmm....combine this with a link shortener and you have much the same effect except the actual state gets stored elsewhere.

Which is totally missing the point and being intentionally daft but it is a little amusing XD

Out of necessity for a very similar issue, I actually wrote a small Javascript utility for this that does all this automatically and uses optional symmetric encryption. Would it be against the rules to post it here?

I’ve been using this hosted on my own server since it was first posted in 2013:

https://news.ycombinator.com/item?id=5696127

Related ongoing thread:

Show HN: URL Snake - https://news.ycombinator.com/item?id=34288577 - Jan 2023 (30 comments)

This reminded me of Xstate (https://xstate.js.org/docs/). Their visual editor in VSCode does this.

I love doing this for playgrounds! It's so nice to be able to share a link with the code embedded. Especially if you're giving someone a bug report and they need a minimal reproduction.

It's pretty common to do this using the URI fragment in a link.

For example: https://themeasureofaplan.com/market-timing/#initialContribu...

This shows the performance of a market timing strategy on the S&P500, where you invest $20,000 upfront and $1,000 per month thereafter, while only buying when the market is 25%+ away from the all-time high price (analysis from 1993 to 2023).

These user input variables are all directly encoded in the URL, after the # symbol.

How much of a concern is the length of the URL? It doesn't matter for bookmarks, but what about sharing? Character limits, or even just the unwieldiness of long URLs in a textarea?

I am pretty certain BeepBox (An online sequencer/tracker) does this as well. It's pretty neat to send something in progress to a friend with just a URL, no accounts needed.

You've just invented video game passwords! This reminds me of transferring over my save data from Golden Sun to Golden Sun: The Lost Age by typing in a 260 character password.

I don't have an opinion on this but do want to mention that LastPass does not (currently) encrypt the URL portion of its entries in the secure vault. Something to keep in mind!

I remember when WebSphere Portal Server used to do this, and the URL would exceed 4096 characters, which was the limit that IE 6 (?) would support, breaking the entire site.

Why not use localStorage or sessionStorage instead of the URL?

It's clever, but I hate it: it makes computing weird and inaccessible to non-technical people, and makes citations etc. needlessly difficult to manage.

Base 64 is probably not the best encoding for this, since the URL allows for a wider range of characters. You can be more efficient by using them as well.

Just thinking - are there any security implications to this? Could sensitive data accidentally get added to the URL and then get intercepted?

Another one would be passing ipfs hash in the url

My favorite example of this is flems: https://flems.io/

doing something like this means you have to pay attention to a few things:

* back/forward button behavior

* cache behavior

* bookmarks over time

surprising there's no discussion of it.

This is really cool, both the state-in-url and the app itself.

Just wondering, how long did it take you to put the app together?

Not necessarily mandatory - but I'd also recommend a stable sort on the keys prior to `stringify`.

Since it is ephemeral, local storage is probably fine? Feels like a better solution.

Your SEO guy is going to throttle you if you even consider thinking about doing this.

But it was done already in widely known in narrow circles PlantUML years ago?

The early 2000's called, they want their ASP pages and IIS license back

Like some other commenters mentioned, this is a cool idea, however by storing JSON data inside base64, the length of the URL blows up very quickly as you start storing more state.

While technically URLs have no formal length limit, various sources suggest that URLs with more than around 2,048 characters start causing issues in browsers, and around 8,196 start causing issues in CDNs (https://stackoverflow.com/a/417184). You can work around this partially by not storing this state information in the query string (path/to?<state>) and instead using a hash string (path/to#<state>), and then extract that data in JavaScript such that it's not sent to the server at all.

IMO, the canonical way to solve this problem is using protocol buffers, which you can then serialize into a much smaller number of bytes, which is then base64 encoded. For example, as mentioned in another comment in this thread (https://news.ycombinator.com/item?id=34314578), Yahoo Finance has a 1,616 character-long URL with 1,572 characters of base64-encoded JSON state:

> {"interval":"week","periodicity":1,"timeUnit":null,"candleWidth":4.3486590038314175,"flipped":false,"volumeUnderlay":true,"adj":true,"crosshair":true,"chartType":"line","extended":false,"marketSessions":{},"aggregationType":"ohlc","chartScale":"linear","studies":{" vol undr ":{"type":"vol undr","inputs":{"id":" vol undr ","display":" vol undr "},"outputs":{"Up Volume":"#00b061","Down Volume":"#ff333a"},"panel":"chart","parameters":{"widthFactor":0.45,"chartName":"chart"}}},"panels":{"chart":{"percent":1,"display":"F","chartName":"chart","index":0,"yAxis":{"name":"chart","position":null},"yaxisLHS":[],"yaxisRHS":["chart"," vol undr "]}},"setSpan":{"multiplier":5,"base":"year","periodicity":{"period":1,"interval":"week"}},"lineWidth":2,"stripedBackground":true,"events":true,"color":"#0081f2","stripedBackgroud":true,"eventMap":{"corporate":{"divs":true,"splits":true},"sigDev":{}},"customRange":null,"symbols":[{"symbol":"F","symbolObject":{"symbol":"F","quoteType":"EQUITY","exchangeTimeZone":"America/New_York"},"periodicity":1,"interval":"week","timeUnit":null,"setSpan":{"multiplier":5,"base":"year","periodicity":{"period":1,"interval":"week"}}}]}

The un-base64'd JSON dictionary is 1,162 characters long, 569 of which is composed of just the key names (48 percent!), and most of the remaining fields likely contain their default value. If this was instead encoded in protobuf, the key names wouldn't need to be included, since fields are referenced by their field ID, and default field values would take up little-to-no space since when the default value is present it isn't encoded into the structure. I presume that, if done efficiently, you could likely make an equivalent representation in protobuf that is 1/4th or even 1/8th the size. You also get, for better or for worse, what is essentially obfuscation for free (yes, you can read out the packed format, but without an equivalent protobuf struct definition it's still hard to tell what field is which, and the entire operation becomes much more labor-intensive).

relevant to mention the new tan-stack router that does this: https://tanstack.com/router/v1

i do this on a site i threw together to annotate youtube videos with timestamps

https://youtubenotes.com/

i used sveltekit and vercel

> Since I update it on every graph edit, I get something major for free -- undo/redo. The browser's history stack becomes my undo/redo functionality.

A pet peeve of mine is that webapps shouldn’t hijack the browsers default functionality, here being back/forward that should refer to pages, not mutations of the same page.

Ideally, one would have a separate undo/redo button on the page for page or url mutations (which should always be in sync). But mutating the URL shouldn’t be done by pushing to the browser history stack, or if pushing one ought to remember to pop the current entry first so the result is a single mutated page on the history stack.

one problem to me is that I run a script remove parameter in url(for tracker) ofc I can set a whitelist but it is a issue i consider

ASP.NET WebForms did this and it was horrible.

Racket does this in its web framework and docs.

I'm just getting a 414 Error

please don't do this, especially if you work with map coordinates.

In other words, tracking

I'm successfully* using it in a few personal projects:

ClickHouse Playground: https://play.clickhouse.com/play?user=play#U0VMRUNUIDE= ClickHouse Dashboards: https://sql.clickhouse.com/dashboard#eyJob3N0IjoiaHR0cHM6Ly9...

The second example shows you why it is not an entirely good idea. The second link cannot be posted in Slack and Google Meet, so I have to use an URL shortener...

Luckily I have it in my disposal: https://pastila.nl/ Example: https://pastila.nl/?02a0d469/8f49f7e4406bd4fbc0e7b142c470dfb...

I'm not into web "programming", but do people really have to abndon binary data storage these days? I think compressing more informaiton produces still more information. While JSON is by no means as heavy as, for example, XML, it's far heavier than just array of int graph[x][y];

Seems like it could be better to store the state in a database and create a unique, short ID that goes in the URL, especially if your doing server rendering (like SSR react or HTMX, or rails/Django)

> I also didn't want to store anything on the backend (at least for the free tier).

You can make the state unique in the DB by a user cookie ID and then upsert the state which will overwrite older state with the latest state. Then you only have 1 record per free user. Remove record that haven’t been modified in 30 days and you don’t have much overhead. Just off the cuff thinking.