Why use an SVG blob rather than an image?
Size and scaling. The blob is one path element, typically a few hundred bytes, and because it is a vector it renders crisply at any size on any display density. The same shape as a PNG large enough for a retina hero section would be tens of kilobytes and would still soften when scaled. You can also recolour an SVG with CSS, which you cannot do with a raster image without shipping a second file.
How do I use the SVG as a CSS background?
Inline it as a data URI, and percent-encode it. The trap is the hash character in your hex colour: inside a URL, a hash starts a fragment, so an unencoded #6366f1 truncates the SVG and the background silently fails to render. Replace each hash with %23, and encode the angle brackets and quotes as well for safety. That one substitution accounts for most of the time people spend wondering why an inlined SVG shows nothing at all.
Should the blob have alt text or a title?
No. It is decorative, which means it conveys no information a reader would miss, and the correct treatment for decorative SVG is aria-hidden="true" so that assistive technology skips it entirely. Adding a title or a description to a background shape actively harms the experience, because a screen reader user then has to listen to a description of an abstract blob before reaching your content.
Can I animate the blob into a different shape?
Not with what this generates, though the shape is well suited to it. Morphing between two paths requires them to have the same number and type of segments, and since every blob here is built from the same spline structure, two generated blobs with the same point count can be interpolated between. You would need a library such as GSAP's MorphSVG, or CSS with the d property, which is animatable in modern browsers when the path structure matches.
Is the SVG generated in my browser?
Yes. The path maths runs locally and the markup is assembled in the page, so nothing is transmitted and no image is rendered on a server.