To answer the question asked, the difference is that the former has "&"
where the latter has "&", in two occurrences. I guess the OP knew that, but
I still wanted to answer the question.
URLs as such are strings used to access some resources, and it depends on
the server how they are interpreted. In this case, at this very moment, both
URLs refer to resources, though with restricted access (I get 403
Forbidden), so one cannot decide whether the difference in the query part
matters. Probably it matters, and probably the latter, with "&", is the one
that should be used.
Well maybe, but here you are probably referring to the use of these strings
in attribute value denotations in HTML, which is quite a different thing.
URLs exist independently of HTML and need not have anything to do with it.
The latter string, if entered as such in HTML, whether in an attribute value
denotation or elsewhere, is syntactically erroneous. Well, technically it
"only" contains undefined entity references, but that's really an error in
practice. And in XHTML it is a well-formedness error, implying that a
browser interpreting the data as genuine XHTML (i.e., XML with HTML tags)
should refuse to render the document at all, just report the first error.
In this case you get lucky because some or all browsers know the
& means just that character and not the starting signal for an
entity reference.
Rather, they know well what "&" signals, but the old practice is to parse
the entity reference and find out that no such entity is defined, then guess
that the string is to be taken literally as if it had "&" instead of
"&".
As it happens, in this case, there is a t
following and no sign of an ";" later (one criterion of an entity
reference).
By classic (pre-XML) HTML rules, the semicolon is not required.
The browser has some error correction algorithms for
some rule breaking and can work this out easily enough. But in a
different url you might not get so lucky.
Or in a different time. The HTML5 drafts list down a large number of new
entities. Luckily they are not yet recognized by browsers, but some day they
might.
Best practice is to use
& to avoid this problem.
In any flavor of HTML, yes. But this does not mean that "&" should be
used inside a URL. (It could, but that would be very odd, and it would have
the literal meaning.) There is a difference between a URL like
http://www.example.com/?foo&bar and the way in which this URL should be
written in HTML markup, namely
http://www.example.com/?foo&bar