|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79045 Incorrect svg mimetypes detected
Submitted: 2019-12-30 01:30 UTC Modified: 2019-12-30 12:20 UTC
Avg. Score:3.7 ± 0.9
Reproduced:18 of 18 (100.0%)
Same Version:2 (11.1%)
Same OS:4 (22.2%)
From: sloth at 0k dot vc Assigned:
Status: Open Package: Filesystem function related
PHP Version: 7.2.26 OS: Centos 7.5
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2019-12-30 01:30 UTC] sloth at 0k dot vc
PHP when given an svg perhaps without the xml header, will return a mime type of image/svg instead of image/svg+xml, however IANA does not list image/svg as an existant mimetype, nor do browsers display it. (

By SVG standards, mimetype returned should always be image/svg+xml, php should also behave consistently for a single type of file. If this is being used to differentiate properly headered SVGs from those that are not as strict, this should be done as part of a file validity check not a mime type check.

Previously reported bug ( was indicated as "Not a bug" due to it being deemed as upstream fault with libmagic. However, libmagic returns svgs missing the xml header as text/plain. This indicates the fault is in the adaptations PHP took to remove that error.

└(~) $ file -i Test.svg
Test.svg: image/svg+xml; charset=utf-8
└(~) $ file -i badge.svg
badge.svg: text/plain; charset=us-ascii

As only php is returning image/svg and this is not a registered mimetype, this can be considered a bug with php.

Test images:
Working svg+xml:
SVG returned as image/svg:

Test script:
echo mime_content_type('./badge.svg'), "\n";
echo mime_content_type('./Test.svg'), "\n";

$finfo = new finfo(FILEINFO_MIME);

$buffer = file_get_contents('./badge.svg');
echo $finfo->buffer($buffer) . "\n";
$buffer = file_get_contents('./Test.svg');
echo $finfo->buffer($buffer) . "\n";

Expected result:
image/svg+xml; charset=us-ascii
image/svg+xml; charset=utf-8

Actual result:
image/svg; charset=us-ascii
image/svg+xml; charset=utf-8


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-12-30 01:41 UTC] sloth at 0k dot vc
-Summary: incorrect svg mimetypes +Summary: Incorrect svg mimetypes detected
 [2019-12-30 01:41 UTC] sloth at 0k dot vc
More descriptive title
 [2019-12-30 02:01 UTC] phpbugs-xap2kka at mpan dot pl
With PHP 7.4.1 returns the same, bug file 5.37 (on Arch) offers a different output:

Test.svg:  image/svg+xml; charset=utf-8
badge.svg: image/svg; charset=us-ascii

That doesn’t explain, however, why is PHP 7.2.26 returning a different value and why “image/svg” is returned instead of “image/svg+xml”. I do understand that badge.svg is not an XML file and one may be tempted to remove that “+xml”, but if it is not an XML, it is also not an SVG and “image/svg” is equally incorrect. Plus it is not the registered type for SVG.
 [2019-12-30 02:03 UTC] phpbugs-xap2kka at mpan dot pl
“With PHP 7.4.1 *it* returns the same, *but* file 5.37 (on Arch) offers a different output” of course. Too many bugs. :)
 [2019-12-30 12:20 UTC]
The result depends on the version of the magic data; for vanilla

as of file 5.38: image/svg+xml
as of file 5.29: image/svg
former versions: text/plain

Note that file 5.38 has been released only two weeks ago, and that
we certainly won't switch back to the pre file 5.29 behavior.

Also note that active support for PHP 7.2 has ended one month
ago[1], so any fix for this could only go into PHP 7.3.

[1] <>
 [2019-12-30 23:20 UTC] phpbugs-xap2kka at mpan dot pl
But on sloth’s system `file` returns a value different than PHP does. This is the primary reason for re-opening and claiming it to be a PHP bug, as far as I understand. Shouldn’t they both agree on a single system?
 [2019-12-30 23:25 UTC] bugreports at gmail dot com
sadly php has it#s own fork of file-libs
in theory you can rebuild "data_file.c"

in reality this works until the distribution has a to new file-libs and in that case the command suceeds but the resulting php binary is unusable

php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c
 [2020-03-25 14:47 UTC] magnar at myrtveit dot com
I also experienced this annoying issue today. Here is a very simple reproduction:
 [2021-07-19 10:17 UTC] tim at decorrespondent dot nl
How is this still a problem after 2 years? The only solution now to properly handle svg files is to manually write an adapter so it will output `image/svg+xml`?
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Sep 17 05:03:37 2021 UTC