Fiddler works by intercepting traffic from the web browser.  They do that by redirecting the web browser to some other port, 8888 in this case, reading the packets and then passing the traffic on thru the standard ports.  It's the same technique used by your anti-virus also.

it is an unregistered port that they 'fiddler' may pay for and get it registered to them

Thanks David.  The link I provided shows 2 "official" registrants for port 8888 (one of them is also listed in your link).  Since Fiddler has been around a long time and hasn't registered the port, it seems to me that software (e.g. Fiddler) which has need of a port for a non-standard use will likely select a rarely used port as default.  Is that the likely answer to my question?

Fiddler works by intercepting traffic from the web browser.  They do that by redirecting the web browser to some other port, 8888 in this case, reading the packets and then passing the traffic on thru the standard ports.

Thanks David.  So I was mistaken: web browsers don't use port 8888 as a rule to send/receive traffic?  What port do they use?

So you're saying that fiddler reroutes the http/https traffic from the default browser ports to port 8888 which they are listening to and then reroutes back to the default browser ports?

In my case, I'm monitoring SoapUI traffic (not browser).  Fiddler didn't see its traffic until I enabled a proxy within SoapUI's preferences for Host: localhost, Port: 8888.  But I don't understand what I did (i.e. the mechanics of what is going on), hence my questions.

Appreciate you guys taking the time to help.  Thanks--

Ah - I think I get it: somehow (in a manner I don't understand) Fiddler reroutes the foreign address for the http/https requests generated by my browsers to port 8888; then after Fiddler intercepts the packets, it forwards them to the originally designated foreign address.  Correct?

yes it is a man-in-the-middle proxy

Thanks Guys--