This is probably more information than you were looking for but to give a more technical answer than the others have given you…
Websites operate in what’s called a “stateless” way.
Most of your applications, say like a computer game, are keeping track of what you’re doing and what you’ve done before. Everything it needs to know, it has stored somewhere in memory or on the hard drive, and that’s all piping directly into everything you see. This is called being “stateful”. It knows what the current state is.
The server that is generating a webpage (by default) has no idea if it has ever seen you before. It doesn’t care how you got there. After it finishes generating the HTML for the page you’re going to view, it forgets everything about you. This is stateless handling.
The purpose of this is that it makes it easy to create an application that needs to be able to handle millions of users. Functionally, you can’t accomplish that. You need to split the users out over a number of machines in order to handle that amount of volume. It’s like at a bank, you can’t just have one teller for everyone. You have to divide the workload out.
So now we could try to ensure that every time your browser comes back to request a new page, it goes to the same server, and then it would be able to keep information about who you are and what you were doing in memory and on the hard drive, but that doesn’t work very well in practice. The machine might crash, the number of users might have grown too large and the system needs to migrate some users to a new server, etc. There’s also the problem that all of the data for all of the users just might be too large. People can sit on the same page for 30 minutes before clicking to the next one. A single server might be handling a million customers who are really taking their time between each request, so it’s not taking a lot of the server’s time to handle each one, so it can handle a whole bunch of them, but if it has to keep their information in memory, then it will still get swamped out that way.
Overall, we want to be able to freely move you around, on every single request, to a new server if at all possible. Maybe we will, maybe we won’t, but if we assume that we might have to do that switch at any moment, then it’s easiest to just run stateless.
So, for example, if you’re looking for events around town. Page 1 might ask you to choose some dates. When you pick the dates, that will create a URL with a start and end date, and the server who sees the URL doesn’t need to know who you are or what you were doing before, it just knows that you’ll be happy so long as it generates a page with information between those two dates. No matter server you go to, so long as you hand them that URL, it will work.
It’s like the rack of forms at the Post Office or other government building. Pick the form, fill it out, and the person at the counter will be able to process the request, no matter which one you get to. If they need to send you to some other agency, they can give you a form for them, and any one of the tellers over there will be able to handle that if it’s one of their forms.
When you sign up a the library, they hand you an ID card. From then on, you carry that with you. It has an expiration date and some information and styling that allows the any person who works at the library to ascertain that it’s really one of their issued IDs. They don’t need to keep a master librarian who memorizes you and every other member of he library and he has to come out and wave you through every time you visit. Just issue a card to you and then anyone can handle your requests.
Sign-in at a website works in the same way. When you first visit and sign in, an identifier is issued to your browser. Every subsequent request, the ID is passed (not through the URL, but through a hidden parameter in the request) and the server can quickly know that you’re the real deal without having to know who you are.
This is all stateless handling.
The URL is like those forms I talked about. Each page has information each needs in order to know what you want. The URL will supply that.
But also like modern day forms, it can have some junk information like, “Hey, you should put your email address in here so we can sign you up to our spam list!”
In this case, it’s usually going to be more innocuous than that, though. Usually a lot of this is more along the lines of information about page or pages that you just came from. The people who make the website want to make the website better. If they’ve just changed something to make it easier for people to find their way through the site, they want to know if their change actually worked. If it makes it worse, then they’ll want to reset it to how it was and come up with a better technique. So each page might insert an identifier for itself into the URL for the next page.
Often a lot of it is also necessary. The URL in the OP contains a second URL inside of it, that’s been obfuscated so that it doesn’t confuse the browser.
Say that I’m sending you to PayPal. PayPal can handle payments for a whole variety of businesses. I need to send them my identifiers, so they know who to send the money to, once you’ve sent it to them, but they also need to know how to send you back to my website. So I’ll stick a URL in the URL for their website.
On my site, you see a page listing your order, then you see PayPal, and then you see a page back on my website that says, “Hey! Thanks! Your order will be ready to ship in 2 days.” To accomplish that, we had to send the “Thanks” page URL to PayPal. That thanks page needs to be able to look your order up, so the URL that we sent to PayPal also needs to include your order ID.
Overall, the URL for PayPal needs to contain:
The site: paypal.com
The function: /send-money
Business ID: business-id=1234567890
- The site: mysite.com
- The function: /checkout-thanks
- Order ID: order-id=ABCDEFG
There can also be a whole bunch of extra stuff for encryption and security, and the previous stuff for tracking, and so on. The tracking information is junk and can be discarded, but most of the rest can’t.