SVG on the page, the phone, and the press
Writing an SVG file and having a particular program draw it are different problems. The format was specified years before it was safe to assume a visitor's browser would show it.
Browsers
Konqueror was the first browser to support SVG in a release, version 3.2, in February 2004. By 2011 every major desktop browser, and many smaller ones, had some level of support. The implementations were not equally finished. A few details from the awkward years are worth keeping, because old pages still use the old habits.
Firefox from 1.5 through 3.6, and some other browsers of that time, would display SVG inside a page only when it was embedded with object or iframe, not with the ordinary img element. SVG could also be included in XHTML by way of XML namespaces. Tim Berners-Lee, who invented the web, was publicly critical of early Internet Explorer for failing to support the format at all. Opera has had SVG Tiny since version 8. Opera 9 added SVG Basic and part of the full 1.1 language. Opera 9.5 had partial Tiny 1.2 support, and it drew compressed SVGZ files. Browsers on the Gecko engine, Firefox among them, have had incomplete support for the full 1.1 specification since 2005. Gecko 1.9, in Firefox 3.0, added a further slice, including filters. Pale Moon, on the Goanna engine, a fork of Gecko, supports SVG. WebKit browsers, Safari, Chrome, and OmniWeb among them, have had incomplete full-1.1 support since 2006. Amaya had partial support.
Internet Explorer 8 and older do not draw SVG. IE9, released on 14 March 2011, supports the basic feature set. IE10 added SVG 1.1 filters. Microsoft Edge Legacy supports SVG 1.1. The Maxthon cloud browser does as well. Native support, once it is actually full, has three advantages that plugins never quite delivered. Nothing extra has to be installed. SVG can be mixed freely with other content in one document. Rendering and scripting become considerably more reliable, because there is one engine rather than a negotiation between two.
Phones
On a phone, support was often limited to SVG Tiny, or limited by the operating system rather than by the browser's ambitions. Adobe Flash Lite could optionally draw Tiny from version 1.1. At the SVG Open conference in 2005, Sun showed a Tiny 1.1 implementation for the Connected Limited Device Configuration, a small Java platform. Opera Mobile, and the browser on the iPhone, included SVG. The Android browser did not, before version 3.0, Honeycomb, even though that browser used WebKit. Before Honeycomb, Firefox Mobile 4.0 beta 2 was the first browser running on Android to support SVG by default.
How much of Tiny a given phone implemented varied with the engine it shipped. Many later phones added gradient and opacity beyond Tiny 1.1. People sometimes called that "SVGT 1.1+." There is no such standard. BlackBerry has had built-in Tiny 1.1 since OS 5.0, and the WebKit-based Torch browser kept it in OS 6 and 7. Nokia's S60 platform draws with SVG. Icons on that platform are generally rendered by the SVG engine. Nokia led the group that wrote JSR 226, the Java ME API for presenting and manipulating SVG, implemented from S60 3rd Edition Feature Pack 1 onward. Some Series 40 phones, the Nokia 6280 among them, also draw it. Most Sony Ericsson phones from the K700 support Tiny 1.1. From the K750 they add opacity and gradients. Phones on Sony Ericsson's Java Platform 8 support JSR 226. Windows Phone has supported SVG since version 7.5. Handsets from Motorola, Samsung, LG, and BenQ-Siemens have shipped it as well. eSVG, a rendering library aimed at embedded devices, turns up on some of those platforms.
In 2003 the 3GPP, the partnership that specifies mobile telecommunications, adopted SVG Tiny as the mandatory vector format for the next generation of phones. Tiny is required, and Basic is optional, for multimedia messaging and for packet-switched streaming. It was later required for vector graphics in the IP Multimedia Subsystem. Neither mobile profile includes the full document object model. Only Basic has optional scripting. Because the profiles are proper subsets, a large share of ordinary SVG still draws on a device that only implements the profile. Tiny 1.2 adds a micro DOM, styling, and scripting, and a few features that 1.1 does not have, including strokes that do not scale with the drawing. Some 1.1 implementations, Opera, Firefox, and WebKit among them, grew those strokes anyway. As phone browsers and desktop browsers came to share code, full SVG 1.1 displaced Tiny 1.2 in practice. The small profile had been a bridge. The bridge was no longer the road.
Compression, authoring, and other programs
SVG is XML, so it repeats itself. A tag name that appears two hundred times is a gift to a lossless compressor. When the file has been gzip-compressed it is called SVGZ and uses the extension .svgz. A conforming SVG 1.1 viewer will display the compressed file. An SVGZ is typically 20 to 50 percent of the original size. The W3C publishes SVGZ files as part of its conformance tests, so "does your viewer open a compressed file" is a question with a known right answer.
You can write the markup by hand. You can also use a vector editor: Inkscape, Adobe Illustrator, Adobe Animate, CorelDRAW. The same programs can rasterise the result to PNG. Inkscape and Boxy SVG can trace a raster image back to Bézier curves, using engines such as potrace, autotrace, and imagetracerjs. The trace is a new drawing, not the photograph stored more cleverly. Fine detail becomes a political decision about how many curves you are willing to keep.
Libraries draw SVG inside other programs. librsvg has been used by GNOME since 2000. Batik is the Java implementation. ThorVG, from 2020, aims at lighter systems. ImageMagick, the command-line converter, uses librsvg and can write the usual raster formats out the other side. For a web application the important mode is inline SVG: an svg element in the HTML document. The drawing then shares the page's events and its CSS, which is why SVG is used for parts of an interface as well as for illustrations. A button that is a drawing can be styled with the same stylesheet as the text beside it.
Outside the browser, SVG is embedded in word processing, LibreOffice for one, and in desktop publishing, Scribus for one. gnuplot can emit it. Paths can be imported into the GIMP or into Blender. Microsoft 365 and Office 2019 can import, export, and edit SVG. On Apple systems the type identifier is public.svg-image, and it conforms both to public.image and to public.xml, which is a neat summary of the whole format. There is even a cottage method, using a spreadsheet's concatenate function, to glue numbers and tag names into a finished SVG document. It works. It is a reminder that the file is text.
On Windows, File Explorer has for years not drawn SVG thumbnails by itself. People add a preview extension, or they use a file manager that already understands the format. A browser is a different question. The browser draws the file. The desktop shell often does not, and the two facts surprise anyone who meets them on the same afternoon.
A document, not a snapshot
SVG can host a script or a stylesheet, in the same way an HTML document can. That becomes a problem when a stranger can upload an SVG, a profile picture for example, and the site treats the upload as an ordinary image. If that file is then used as a CSS background, or as a logo, or in a gallery, the browser may run the script when it loads the image. A hostile file can lock the browser up by forcing an absurd amount of work. It can also lead to HTML injection and to cross-site scripting. The W3C therefore sets extra requirements for the case where SVG is used simply as an image.
Inline SVG, an svg element that is part of the page, is a different case. The W3C treats it as less of a surprise, because the content is part of a larger document and script on that page is expected. The practical rule is short. Do not accept an SVG upload and serve it back as a trusted picture unless the file has been checked. The details of those checks are in the W3C's rules for SVG-as-image.
One standards cousin is worth naming. MPEG-4 Part 20, Lightweight Application Scene Representation and the Simple Aggregation Format, is based on SVG Tiny. It was published as ISO/IEC 14496-20:2006. It adds things a mobile service wants: dynamic updates, a binary encoding, a compact way to carry fonts. SVG also appears in MPEG-4 Part 11, in the textual XMT representation. The web format and the mobile-multimedia format are relatives. What the file contains is the same vocabulary either way. Where graphics are put to use is the older reason any of this was worth standardising: a small, sharp picture, repeated everywhere a page needs a mark.