The ChessScanner app provides QR codes and URLs like https://chessqr.com/viewer?q=01GLEcQZ8IcFcjpjvG9BSfr3&w=MFH&b=N.N.

I have not yet been able to reverse-engineer the "q" value. It seems to start always with 01, I guess this is just a version specification. Thereafter, it seems that there's an urlsafe_base64 encoded string (using '-_' instead of '+/' w.r.t. standard base64), although in some rare cases it has length 4k+1 which can't be a valid base64 string... but always including the "01" or just the "1" doesn't work out better.

In any case I think that would be the way to go (use urlsafe_base64 encoding for the move list, see below for more) for your purpose.

The length of chessqr's q-string, without the initial "01", is about twice the number of moves (here "01"+ 22 characters for a game of 11 moves). Since one character represents 6 bits which could represent exactly one square of the 8x8 chess board, one might be tempted to think that it could be simply the UCI move specification, i.e., departure square + destination square (+ 2 (or 3 or 4 or 6) bits to specify the piece in case of promotion). However, it doesn't seem to be that... (I would be much interested if someone knows or would like to [maybe jointly] figure this out!)

Another way that has been considered for recording chess games in very few bits per move (cf. this discussion on rec.games.chess) is to create a list of moves, which will usually give much less than 64 x 64 possibilities: one can expect an average of about 40 moves which should usually fit in a single 6-bit number. I guess it could be possible to construct positions with more than 64 possible moves, but then you could use 0o77 (octal 63) as an "escape code" for, say, a move number with 2x6 bits.

OR, you use a variable bit size and use only as many bits for the next move as correspond to the maximum number of moves (i.e., as long as there are ≤ 32 moves possible, use 5 bits; as long as there are ≤ 64 moves possible, use 6 bits, etc.). I guess that might be very efficient under the assumption that very often, there might be even less moves available.

You might still want to use an "escape code" (maybe zero or the maximum value with all bits 1) to introduce a "special move", e.g. "end of game" (resign or draw...) or to allow for illegal moves (then probably the UCI notation will be required, to give both, starting and destination square).

For the metadata (PGN header), I think it should be OK to give the data in the form of "&variable=value" pairs, but if you really want to get it as short as possible, you could obviously also use zlib + urlsafe_base64 encoding of the compressed data.