From my experiments a while back it seems that allocations only really work if you enable shared memory.
However shared memory needs additional CORS headers to be set, because by default browsers disable shared memory, because it can potentially be used to create side channel/timing attacks. This is basically so that a random ad embedded into a website isn’t allowed to use shared memory.
I don’t think I have seen any working allocating example that doesn’t use shared memory. So either set those headers, or use the reloader that @tobyjaffey uses in his demos Framebuffer and Audio WASM demos here GitHub - ringtailsoftware/zig-wasm-audio-framebuffer: Examples of integrating Zig and Wasm (and C) for audio and graphics on the web
A whole other way is to just not allocate, this only works if you could instead use @embedFile to directly embed the files into your program (only makes sense if they are tiny enough and don’t change too often) and if your other allocations can be turned into fixed size allocations.
I am not entirely sure, but I think it is also possible to use a fixed-size allocator if you can estimate an upper bound for max needed memory.
That said, I think if you need dynamically growing memory in the browser, you will need to enable shared memory.
So basically I think you aren’t even getting to the point where you are trying to load the file, instead you probably already error trying to allocate memory.
Another possibility would be to use emscriptens --embed-file path option which also can be used with a directory to embed a whole directory of assets into your generated webassembly output.
The benefit with that is that it can make it so that your app works pretty similar in desktop and web (not requiring many changes), because emscripten basically packages the file somewhere into its virtual file system and just delivers them alongside your webassembly (I think it ends up in a .data file alongside the .wasm)