Awesome idea - relates to #11

I'd be keen on this as well, but I'd propose a different implementation.

Rather than a query parameter per plugin, the site should accept two parameters:

• config with the JSON config that SVGO accepts, this can be a URL parameter.
  • For the plugin array, will have to account for strings and objects with the name property, and ignore unknown plugin names or objects that don't match the schema.
• svg which should be stored in the fragment instead of a query parameter.

If the config query parameter is specified, the webapp will parse and adapt that config to the interface.

If a fragment is specified and starts with svg=, the webapp will parse and initialize the workspace with that SVG. This will also make handling the request faster for large SVGs since it doesn't have to be sent to a server.

The reason for keeping the SVG in the fragment is for privacy/confidentiality. Clients like cURL or browsers never share the fragment with the webserver, which prevents users or employees from unintentionally leaking their SVG to the server.

The webapp can have a Get shareable link button, which populates the query parameters and fragment with the current workspace, and copies to clipboard. This allows for sharing the workspace without a database.

My use case is that I'd like for the SVGO documentation's demos to link to SVGOMG with the SVG and config for users to explore. Similar to what MDN does with having a Play button on each example.