the receiver properly implements replay protection using jti and exp
but in case it is used as a token that can repeatedly be used e.g. against an API then supplying it as a query parameter is less preferred since it may end up in logs and system process information, available to others that have access to the server or client system. In that case would be better to present it as part of a header or a POST parameter.
Besides that, by using it in the query parameters you may run in to URL size limitations on browsers or servers; using it in a header provides some more space, using it as a POST parameter would work best.
Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?
Yes, insofar that a JSON Web Token (JWT) is encoded in a way that it is transparent with the encoding of a query parameter in an URL:
A JWT is URL-encoding-safe. There will be no data-loss when used in-place; no additional encoding is required; it is even URL encoding safe inherently, applying url-encoding (percentage-encoding) on the JWT multiple times will not destroy it.
This safety is limited:
There can be a data-leak when used in-place if the URL itself is part of such a data-leak. By how URLs are commonly in use, you should treat any JWT in an URL query parameter as-if the data-leak already happened and therefore prepared the JWT for it already (e.g. prevent replay attacks).
And it will be at best as safe as the transport of the URL information is, and never more safe.
And if the transport of the URL information is not safe, everything in the URL can never be more safe either, which includes the JWT when used as a GET parameter.
Apart from using it in an URL (which looks to me as a mechanism of transport), you may want to consider additional data-retention, protocol and even your own systems properties, including those of the JWT in question itself.