Php + js multiple product photos upload processing?

first of all, my current practice
is to upload multiple product photos when adding new product photos at the front desk
each picture will have a hidden input, with base64 in it

<input type="hidden" name="icon[]" value="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAacAAAJ7CAYAAABH+15RAAAKsGlDQ1BJQ0MgUHJvZmlsZQAASImVlgdUU1kexu976Y0...">

then download it to the specified directory using file_put_contents in the backend php

foreach ($_POST["icon"] as $value) {
    preg_match("/^(data:\s*image\/(\w+);base64,)/", $value, $result);
    $typeThis = "." . $result[2];
    
    file_put_contents("../../images/product/cover-XXX".$typeThis, base64_decode(str_replace($result[1], "", $value)));

it"s just that the length of this string is really interesting
and then if you upload a picture of more than ten MB, you simply don"t give it (it should be because the base64 string is too long, as if it has something to do with SIZE)
is there any other way to have the same effect, but a cleaner way, you can upload a picture as big as it is not so long? Can you grab it at the back end in the same way?

first of all, thank you for the invitation. is not familiar with the backend. Let me give you some points on the front end: in the technology selection of file storage, the use of object storage is preferred. Every cloud service platform should have this product line. One of the advantages of object storage is that it is stored in files and does not depend on specific servers or paths (of course, some paths for classification or processing can be created by yourself), so that you can share them when you do cloud load balancing. moreover, if you suddenly want to manage it separately one day, like Aliyun OSS, which I have used, there is a separate client that can be used, and logging in is completely visual, which is not much different from operating Windows. Second, it is not afraid of capacity explosion. I remember making a marketing type page, Mini Game, a few years ago, which requires users to send their heads up, directly pile up the hard drives on the day they go online, and temporarily go offline to expand their capacity. If you use object storage, Money will make everything easier to say. ? of course, if there is enough server space for a single host, there is nothing wrong with choosing to store it directly on the host, but it is not recommended to use Base64, because the file is stored in binary. After the file is converted to Base64, the binary becomes ASCII code, which expands at least 3 times the size (the string takes up binary digits). If it is not compressed, this number is very scary. In turn, it will directly lead to the user's picture card can not be transferred at the front end or the resources on the page can not be displayed (in fact, even if it is passed, it seems inappropriate for tens of megabytes of strings to be stored in the database. Of course, I said basic), so don't rashly use this scheme for the sake of ostensibly "can be converted to a string database", unless your pictures are small things with an average of a few k. I personally suggest compressing the front-end method and then passing it to the backend. The purpose of compression here is to directly control the size of the picture, the second is to do normalization pre-processing, the EXIF and other things first clear, if you need high quality, you can output the original size of PNG. Of course, if you use object storage, you may still have the opportunity to use some additional tools to do secondary processing in the background. Direct download at the backend is not recommended. From the perspective of user experience, it is recommended to give users a more intuitive feedback, but also to remind users of the need to "take the initiative" to complete the operation, so that users will upload the picture according to the habit and then do something else. If it is silently loaded in the background, and the user closes the page before loading, isn't it in vain?