Technically, the accepted answer is a bit off
It may not matter much in this particular case. Nevertheless, as this page pops up prominently in searches, we probably should set things right, ya?:
There is just one sRGB
Incorrect. The original sRGB specification from the IEC discusses two flavors of sRGB, and later years saw the addition of a number of sRGB variants. BUT WAIT THERE'S MORE and I am going to discuss them below.
Most browsers recognize just ICC v2
Not Relevant. The OP said he is stripping the profiles, so it does not matter at all what version profile he uses. Not at all, as there will not be any profile to read!
sRGB has well defined ... "gamma"...
Not Really. The sRGB TRC encoding is specified with a piecewise tone response curve, which is not a "gamma" function, though the spec does permit EOTF using a gamma curve with a 2.2 exponent. Yes, even the spec has more than one transfer curve indicated.
AND: it is important to know that there is further variation in the various ICC profiles. More below.
...and it predates ICC,...
Incorrect. The ICC was formed in 1993, and sRGB was created in 1996. 1993 predates 1996. The ICC published the v4 spec in 2001 but that's irrelevant.
Answering the OP
I want to convert to sRGB & then remove the sRGB profile from the image
Okay, this is a common practice and has some advantages. Up to CSS3, sRGB is the default colorspace for web content, meaning that the specified page colors are relative to sRGB, and untagged images should be interpreted as sRGB, and therefore remain relative in color to the CSS colors chosen in your styles. This is probably the biggest factor in favor of using untagged sRGB images.
As it happens, some browsers that do read embedded profiles do NOT adjust the CSS colors to a given output intent. I.e. there are some cases where the image is adjusted, but the page colors are not.
Human color perception is endlessly fascinating (at least to me, LOL) and we have a feature we call "color constancy". The truth is, it is less important that the monitor emit exact, absolute color combinations.
It is more important that everything DISPLAYED on the monitor maintains the same consistent colors relative to each other (all the content on the monitor.) I.e., you design a page with a color scheme, and you want the image to maintain the same relative color distances to the page.
If your sRGB image has an embedded profile, then if the browser adjusts the image but not the page colors, the relative colors will shift. This is the behavior of many browsers. (One exception is MacOS Safari, which is color correct/color managed for everything.) CSS4 in the near future is going to add other color spaces, though sRGB is expected to remain the default.
So which sRGB profile [is] correct to convert my picture for the web? Why so many different sRGB profiles?
The answer here is... use your monitor profile.
Wait... WUT?
It is more important that your workspace is calibrated for sRGB and that your test browser uses/assumes sRGB for all colors on the page, both the CSS colors and the images.
As you are going to strip your profiles out of the images, using your monitor profile for your working space means your photo editor window needs to (and should) match the CSS colors in your browser windows. Then WYSIWYG. What you see is what you get, and with everything untagged, the relative colors should be consistent everywhere.
But what about wide gamut monitors? Yea, things may look more saturated on them, but again, color constancy effect. You want all the colors between your images and your CSS styles to remain relative.
Under No Management...
Did you know that when you watch TV, there is no color management? Programs are color corrected on calibrated systems in studios, adjusting the look in a "WYSIWYG" environment, and then streamed out to the world with no color management.
When you design a webpage, your CSS colors are not color-managed in most user's browsers, and if your image colors are also not managed, then they should remain the most consistent as a total page of content.
But this does require that you set up your work environment for consistency, and also test your content on several different browsers on several kinds of devices.
But what if you still want a color managed working space...
Fair enough. Then you want your final working space to be your delivery space, sRGB. The profile I like for a TRC encoded working space is sRGB-elle-V4-srgbtrc.icc
When I say "final working space" what I mean is, if you are prepping images for multiple destinations, some web, some print, etc, then you might be needing to work in a larger space for the main image editing (such as ProPhoto, Rec2020, or ACES, etc — and importantly, at a higher bit depths, as in 16bit or 32bit float).
From your larger space, the print images get converted to CMYK, and the web images get converted to sRGB using sRGB-elle-V4-srgbtrc.icc. Then do some final adjustments if needed, and output to 8bit with no embedded profile.
Final Thought
Reading the above, you might think I didn't appreciate color managed workspaces, but I definitely do. I use color management most of the time. But if your destination is a non-color-managed environment with a defined standard colorspace, then it is more important to be in a calibrated version of that colorspace.
Best of luck!
