I agree with the comment that Srikant made. It seems to me that you have something in your code that attaches /lib/tgn/ to the beginning of the url line, which ends up putting it in front of data to create /lib/tgn/data:image/png , which is invalid.
You need to track this code and ignore it together if it is a data uri, but at the same time it allows you to add a path to images that are saved and accessible in the /lib/tgn/ .
Explanation added
Based on your comment, I'm not sure what we are saying clearly. What I see in your above published code for the "query that generated the image below" is:
cs_uri_stem="/lib/tgn/data:image/png;base64,iVBORw0KGgo... [etc.]"
And the image you posted shows the values of cs_uri_stem , all of which have /lib/tgn/ inserted before data:image/png . Something (maybe your combination of CDN, maybe rewriting the rules on your server or something else) seems to call the code /lib/tgn/ , which will be added to the css url() code during the process / request (so it seems like this is not being added directly to CSS, because neither your reduced nor extended code shows it being added). But the end result, which shows your hosted image, points to cs_uri_stem causing 404 errors that have /lib/tgn/ added before data:image/png . Thus, the browser does not treat url() as data , because the request starts from the path , namely /lib/tgn/data:image/png ... Since he believes that he is looking for a file starting with the path /lib/tgn/ , then the browser issues a request that (of course) it will never be executed, and therefore, a 404 error will be generated.
Now, maybe I still don’t understand what you said in your comment, but perhaps I have set myself a clearer idea of what I think your problem is.