Now that you've seen an example of a drawing created with SVG, it might be useful to take a second to explain the VG in SVG and why that makes the file format scalable.
With raster (bitmap) file formats, you're probably familiar with formats such as JPG, PNG, or GIF. You can think of the image data as being stored pixel by pixel, so each point in an image is stored in the file and read out by the browser or graphics program pixel by pixel and row by row. The size and quality of the image is constrained by the size and quality at the time of creation.
There are optimizations for all the bitmapped file formats that limit the actual amount of data stored. For example, GIFs use the LZ77 algorithm to collapse redundant pixels down to a backpointer and reference pixel. Imagine if your image has 100 pixels of pure black in a row. The algorithm will search through the image for a sequence of same-bytes and when a sequence is encountered, the algorithm will search backwards through the document to find the first instance of that pattern. It will then replace all those pixels with instructions (a backpointer) on how many characters back to search and how many pixels to copy to fill in the number of same-bytes. In this case, it would be 100 (pixels to search) and 1 (pixels to copy).
Vector graphics, on the other hand, are defined by vectors and control points. To simplify significantly, you can think of vector graphics as being a set of numbers that describe the shape of a line. They may be a set of specific points or they may be, as in the case of the circle earlier, a set of instructions on how to create a specific type of object. The circle element doesn't store every pixel that makes up the circle. It stores the arguments used to create the circle.
Why is this cool? One reason is that because it's just a set of instructions defining the shape, which you can scale in or out, and the rendering engine will just calculate new values accordingly. For that reason, vector graphics can scale infinitely without loss of fidelity.
If that's all confusing to you, don't worry about it. The more you work with them, the more familiar you'll be with the way vector graphics work. In the meantime, the following set of examples and figures will help to illustrate the difference. First, look at the following markup. It represents four images, using the exact same SVG image as the source. The image represents the SVG logo. The dimensions are set at the image's natural size and then 2x, 4x, and 8x, the image's natural size:
<img src="svg-logo-h.svg" width="195" height="82" alt="The SVG
logo at natural dimensions">
<img src="svg-logo-h.svg" width="390" height="164" alt="The SVG
logo 2x">
<img src="svg-logo-h.svg" width="780" height="328" alt="The SVG
logo 4x">
<img src="svg-logo-h.svg" width="1560" height="656" alt="The SVG
logo 8x">
Rendered in the browser, that markup produces the following. Notice that it's completely crisp all the way up to 8x, the original size:
Now, look at the same markup, this time with PNGs. It follows the same pattern:
<img src="svg-logo-h.png" width="195" height="82" alt="The SVG
logo at 'natural' dimensions">
<img src="svg-logo-h.png" width="390" height="164" alt="The SVG
logo 2x">
<img src="svg-logo-h.png" width="780" height="328" alt="The SVG
logo 4x">
<img src="svg-logo-h.png" width="1560" height="656" alt="The SVG
logo 8x">
But now, see the result. Notice that, at the natural level, there is no difference between the SVG and PNG. The pixels in the PNG are enough to match the vector-defined lines in the SVG Version. Also, notice how the image gets progressively worse as the image gets larger. There is no way for the browser to get more information (more pixels) out of the bitmapped format to fill in the details at the larger size. It simply scales up the pixels that it has, with terrible results (especially at the 8x level):