I just launched iSVGEditor.com, a simple tool for editing SVG icons, especially for non-designers like me.

As someone who frequently works with SVGs in my web projects, I often want to tweak things like colors or shapes. While these changes can sometimes be done with CSS, I decided to build my own editor to make the process easier and more intuitive.

This is the first step in a larger project I'm working on, and I’d love to hear your thoughts or suggestions as I continue to improve it.

Check it out at iSVGEditor.com, and feel free to share any feedback!

I’ve been working on JSONtr.ee, a web platform for visualizing and graphing JSON data. While building it, I ended up creating my own lightweight JavaScript library to help anyone convert a JSON file into a schema graph.

Before creating this library, I used MermaidJS, but I ran into significant limitations, especially with large and deeply nested JSON objects. My library was built to handle these cases better and to offer more flexibility for customization. After solving my own problem, I decided to make it available for free to anyone who might find it useful.

Key features: Transforms JSON into schema graphs. Handles large and complex JSON objects seamlessly. Built with simplicity in mind – dependency-free and easy to integrate.

Why I made this: While working with APIs and large webhook payloads, I struggled to understand nested structures using standard tools. This library makes it easier to visualize the data as a graph and explore it interactively.

I’d love to hear your feedback, suggestions, or any ideas for improvement.

Thanks for taking a look!

To showcase it better, I'd like to see more complex objects on the initial reveal, so I don't have to go and find & format a JSON object just to see if the app/library is worth using yet!

I could definitely see using this, but don't think it solves anything for me right now.

I think if the diagrams didn't require horizontal panning, and/or supported interactive collapsing, it would be more effective. As it stands, the text view on the left side of the screen is actually easier to parse at a glance than the tree.

Generally, vertical scrolling is more natural for reading this kind of data, and also works better on mobile.

So a first guess of an improvement is something like: the tree diagram generally grows flat & vertical, with horizontal panning (or a manual "expand" click) reserved for deeply nested objects.

Looks great! Thanks OP for sharing!

As a developer, I often struggled with making raw JSON more readable and debugging complex structures. While tools like JSONLint are great, I noticed it breaks when dealing with JSON containing single quotes, which led me to create JSONtree. It offers: Automatic formatting and beautification of JSON. Interactive tree diagram generation for better visualization.

I'd love your feedback on how it could be improved or what features you'd like to see. Thanks for checking it out!

Long term, how do you intend to sustain the service if users become dependent on it and need to use it at scale?

How do you intend to maintain reliability and uptime for users whose business depends on access to the service?

What happens to users if/when you lose interest/ability to continue the project?

Don't get me wrong, you don't owe other people anything. On the other hand, free is often a way of avoiding really hard (and very interesting) engineering problems. People are the hard part of engineering.

However, this is a double-edged sword: I might encounter sites with a large number of internal pages, which would complicate the resources needed to provide an efficient and sustainable service.

Another option I've thought about is offering a CDN service to directly serve optimized images, improving performance without the need for users to manually download and upload images. It does become more complex when charging users, as reliability, support, and infrastructure take on a much greater role.

My question is - why does this require a server?

Write it in something that compiles to LLVM / WASM and just make a static page. Infinitely scalable and just pay for the domain (and CDN provider if applicable) both likely nominal cost.

You might still be able to offset a portion of the compute by just figuring out the URLs of the images on the back-end, sending that list to the client, which would then download and do the optimization / resizing.

Is what I was responding to. Wasn't criticizing the posted product implementation choices or demanding a rewrite. I see how it could be read that way, which is unfortunate.

Parent comment asked a number of questions that all suggested a server was a requirement. If scale becomes any issue for a service like this, there are approaches other than shutting down the service due to server / maintenance costs.

You can make it easier for your users to read the policies if "policies" is a link to your policies. Also, I think you mean "moment to" instead of "momento."